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

[Manik Surtani]

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 at jboss.org
Telephone: +44 7786 702 706
MSN: manik at 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 />