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