This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I am trying to clear some doubts with Hibernate for getting a Job ASAP . so please help me .
If one configures Ehcache as second level cache with Hibernate and uses a READ_WRITE strategy as say <cache usage="read-write"/>
"Then my understanding with respect to above is that " Whenever there is a change of the entity at the database level the cache is also updated simultaneously " please tell me if i am right or wrong on this .
If someone underwrites the data in the database, and your Hibernate Session doesn't have a lock on that data, I can't see how Hibernate could update that second level cache. It's not really just a deficiency in Hibernate. It's just a matter of controlling how many different fingers are in the database pie.
Pessimistic locking of resources in a database backed application is almost always a bad idea. It turns a resource designed to support concurrent access to one that only supports serial access. You would normally use an optimistic locking mechanism to check before update if things have changed (to prevent lost updates) and in the case of a second level cache you would also carefully choose the data you allow in this cache, since frequently updated data is not a good candidate for a cache.