Newly created object in hibernate session 1 can't be gotten by id in session 2 (intermittently)

66 views
Skip to first unread message

Luis Arias

unread,
Feb 16, 2012, 5:09:48 AM2/16/12
to hibernate...@googlegroups.com
Hi,

I'm wondering if this is theoretically possible because I'm seeing some strange behavior in our automated functional tests.  The following takes place in a single web request. A new instance of a User object is created in a new hibernate session and within a transaction, right after that an attempt to retrieve the instance in a pre-existing but different hibernate session fails in  our automated tests every once in a while, I'd say maybe 10% of the time.  I'm wondering if because of the asynchronous nature of updating memcached + latency due to using ElastiCache this situation is theoretically possible ?  I'm surprised that memcached would have anything to do with this since we are talking about a new instance, but maybe hibernate-memcached has an impact on session flushing ?  When checking the database after this error the new User row is definitely there.

Luis

Ray Krueger

unread,
Feb 16, 2012, 9:27:15 AM2/16/12
to hibernate...@googlegroups.com
>
> I'm wondering if this is theoretically possible because I'm seeing some strange behavior in our automated functional tests. The following takes place in a single web request. A new instance of a User object is created in a new hibernate session and within a transaction, right after that an attempt to retrieve the instance in a pre-existing but different hibernate session fails in our automated tests every once in a while, I'd say maybe 10% of the time. I'm wondering if because of the asynchronous nature of updating memcached + latency due to using ElastiCache this situation is theoretically possible ? I'm surprised that memcached would have anything to do with this since we are talking about a new instance, but maybe hibernate-memcached has an impact on session flushing ? When checking the database after this error the new User row is definitely there.
>
Seems like a pretty fragile test. It sounds like there are numerous points in which a mere moment of latency is going to break that test. I wouldn't think hibernate-memcached would be causing any of that though. Try running that test a few times with no caching and maybe try running it again with just the session based second level cache enabled. Maybe that will shed some light on the issue.
-Ray


Luis Arias

unread,
Feb 29, 2012, 3:23:18 AM2/29/12
to hibernate...@googlegroups.com
Hi Ray,

Wow I did not get a notification on your reply, sorry to be getting back to you late. I'll check my settings.

I was wondering if you could explain how hibernate session flushing interacts with hibernate-memcached.  I know that the spymemcached implementation is mono threaded and uses java Futures to pipeline access to the memcached daemon.  Given this mechanism, is there anything in hibernate-memcached that guarantees that second level cache is up to date before returning from the hibernate session flush, let's say at the end of a transaction, by waiting until memcached has been effectively written to ?  Is so could you point that out to me in the codebase ? I'm worried that we may be hitting an out of sync second level cache after the end of a transaction if that is not the case or if the implementation is faulty.  We see this during automated tests a lot because selenium makes requests a lot faster than a human user (we could slow it down but want to get to the bottom of this), but also under conditions of increased concurrency, for instance when N background tasks are inserting data concurrently (and these we do not want to slow down since we would like them to run as fast as possible).

Luis

Ray Krueger

unread,
Feb 29, 2012, 8:55:09 AM2/29/12
to hibernate...@googlegroups.com
Luis,
All writes through spymemcached are asynchronous so there is no guarantee the data will be there immediately. That has always been the case though. 

The code is on github if you'd like to dig in. If you do find an issue I'll gladly merge it and cut a new release.
--
You received this message because you are subscribed to the Google Groups "hibernate-memcached" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hibernate-memcached/-/ijraBe9tv84J.
To post to this group, send email to hibernate...@googlegroups.com.
To unsubscribe from this group, send email to hibernate-memca...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hibernate-memcached?hl=en.
Reply all
Reply to author
Forward
0 new messages