Re: [jbosscache-dev] Re: JBoss Cache and Hibernate Integration

On Fri, 2007-03-16 at 01:23 +0000, Manik Surtani wrote: > Guys, > > I've updated the JIRA [1] and the Javadocs on the Cache interface [2] > to reflect the new functioning of putForExternalRead(), which I will > implement by 2.0.0.BETA2. This looks like a reasonable specification to me. > Just like to clarify that there was also some thought around using > READ locks for the call when pessimistic locking is used. There was > also talk about potentially forcing READ_COMMITTED as an isolation > level for this call if the isolation level used is anything > stronger. Probably points I should have brought up on the call, but > are there any thoughts around these? > > I'm happy with using a RL instead of a WL simply because we intend to > only carry out this operation if the node does not exist (see first > bullet point in the javadoc). Because of this though, I don't see > how forcing READ_COMMITTED can benefit much, and would just add > complexity unnecessarily. Because the current transaction is suspended, REPEATABLE_READ vs. READ_COMMITTED seems pretty much irrelevant ... we aren't going to hold any locks after the operation finishes. That, and the fact that the node doesn't already exists, also means that the difference between write locks and read locks is pretty small ... the only difference is what happens when someone else reads between: - The update to the node finishes - We release our locks Right? As long as data-structure integrity is preserved, using a read lock should be OK, but I think the distinction isn't going to matter much. (This is, of course, because JBossCache doesn't acquire locks across the cluster on a write, but just lets the transaction roll back on commit in case of conflict. If JBossCache did acquire cluster locks on a write, then a write lock would be much more expensive and avoiding it a big win.) - Owen