[hibernate-dev] Re: [jbosscache-dev] Re: JBoss Cache and Hibernate Integration
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.
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.
Let me know your thoughts!
Cheers,
Manik
[1] http://jira.jboss.com/jira/browse/JBCACHE-848
[2] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss/JBossCache/src/
org/jboss/cache/Cache.java?view=co
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 26 Feb 2007, at 16:45, Manik Surtani wrote:
Ok, so my notes from the call, based on issues from the wiki
1. Multiple caches will probably only formally make it in the next
major Hibernate release - 3.3.
2 Notes on putForExternalRead() functionality, in addition to the
solution presented on the wiki:
- PFER only goes through if node does not exist; no-op otherwise
- Force asynchronous mode for replication or invalidation to
prevent any blocking
- 0ms lock timeout to prevent any blocking here either. If this
fails, PFER is a no-op
- no to separate thread necessary, since we will be operating with
a 0ms timeout, async replication and a no-op if the node exists.
The only real chance of any blocking here is JGroups FC which is
considered small enough a case.
3. Since JBC 1.4.1.SP1, write locks are not acquired on parents
when adding or removing children, to be more accurate to repeatable
read semantics. WLs can still be acquired on parents if enabled in
the configuration (see "LockParentForChildInsertRemove" in http://
labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/
1.4.1.SP2/TreeCache/en/html/configuration.html, which defaults to
false). As such, this contention should no longer be a problem.
4. Brian implemented for EJB3 clustering in AS 4.2, will make it's
way back into HIbernate in the 3.3 timeframe?
5. Do nothing for now since the urgency is removed. Only fails on
old versions of JBoss TS. In future (JBC 2.1 timeframe) look at
what the microcontainer has to offer with synchronisation
registrations.
6. Coordination issue
7. Galder to come back with more details here, but general
consensus is not to perform transparent retries.
Feel free to add stuff I may have missed or further thoughts. Very
useful and productive call!
Cheers,
Manik
<SNIP />