Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 08 | Comments: 18

filter by tags archive

A bug that drove me crazy!

time to read 1 min | 98 words

I am ashamed to say how much time and effort (and at least one complete re-design) this bug has cost me.

Take a look at the following test, meant to show that Raven can replicate deletes between servers:

image

There is a very subtle bug in this code, which completely tripped me.

Here is a hint, the session interface is the high level client API for Raven.

Can you spot the bug?


Comments

Rafal

A session-level cache doesn't know that underlying data was deleted after it has been read for the first time?

Markus Zywitza

If loaded once successfully, the non-null object is cached by the session.

Benny Thomas

if (company == null) is the bug

if (company != null) is the correct thing you want to do.

Those thing are can drive one crazy

Steve Py

My guess would be along the lines of Rafal..

I don't know RavenDB but I'd guess there'd be a parameter available on Load() to ensure a clean hit to the document source. (I.e. NoCache)

Rob Ashton

Caching is the answer from my glance

Rob Ashton

But that's only because you hinted about it being about the session, I'd not have seen that - and I'm fairly sure I've done similar in NH before by accident!

Glenn

Yeah, I was thinking cache too.

Bernhard

I'd like to jump in and say that it appears your test is missing a pre-condition.

I think you should ensure "companies/1" exists in store1 and store2 before you delete it from store1, and poll store2 until timeout or it no longer exists.

I'm not aware of the specific syntax for RavenDB [yet] but I am surprised that there is no query you can use to see if "companies/1" exists other than to load the company.

I assume RavenDB will return null if the requested document is not found?

Benny Thomas

Damn, my answer came to fast, truly newbie...

Kristian Erbou

If there is a Flushmode enumeration in the Raven Client API (similar to NHibernate) my answer would be that Flushmode is set to Never on the sessions you get back from your session factory.

Mistertom

I think the session should be opened inside the for loop.

Dhananjay Goyani

+1 for Mistertom, Steve Py and Markus Zywitza. ;-)

kamil

What about transactions?

Bogdan Marian

I know that NHibernate session does not sync its content with the DB unless you either commit the transaction or call its Flush method. I do not know if a RavenDB session acts in a similar way, but if it does, I see no transaction commit or flush, so your company was not deleted yet ...

Diego Mijelshon

Two variations on what others said: if the session is like NH's, Load might never return null OR it might never go to the database twice for the same ID in the same session, so the session should be opened INSIDE the loop.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Concurrent max value - 2 hours from now
  2. Production postmortem: The case of the memory eater and high load - 3 days from now
  3. Production postmortem: The case of the lying configuration file - 4 days from now
  4. Production postmortem: The industry at large - 5 days from now
  5. The insidious cost of allocations - 6 days from now

And 5 more posts are pending...

There are posts all the way to Sep 10, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    14 Aug 2015 - The case of the man in the middle
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats