jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosmin Lehene <cleh...@adobe.com>
Subject Re: AW: NoSql Support
Date Wed, 17 Aug 2011 11:37:38 GMT
First I'll have to better understand what a bundle is :) (JCR newbie
here:)). I'll try to read about it.

Hbase supports row locks. This translates to atomic operations. However
this is not really a transaction per se as there's no external rollback
mechanism and Jackrabbit is external.
If a row is updated in more than one step than a more complex rollback
mechanism should be considered. And this shouldn't rely on exception
handling as it could be the Jacrabbit server that's failing during the
transaction.
I guess a row flag (e.g. committed) could be used to get transaction state
persistence at Hbase level with some logic in Jacrabbit that would check
the flag when doing operations.

When more than one row is involved a transactional region server would not
be of much help as the range of rows could span on two or more regions
served by different servers.
We've implemented a transactional prototype once, but that might be out of
the scope of this implementation.

Cosmin


On 8/16/11 4:51 PM, "matthew.l.donnelly" <mdonnelly@proteuseng.com> wrote:

>Cosmin,
>
>There is a method in HbasePersistenceManager where it looks like
>transaction
>functionality is needed:
>
>public synchronized void store(final ChangeLog changeLog) throws
>ItemStateException
>
>pseudocode
>try{
>    conHelper.startBatch();
>    super.store(changeLog);
>    conHelper.endBatch(true);
>}catch(Exception e){
>    conHelper.endBatch(false);
>}
>
>
>I just looked through the AbstractBundlePersistenceManager(which
>HbasePersistenceManager impls).  The store method appears to be performing
>operations that are cached within the parent class, by making calls out to
>the child.  Operations that the parent is calling include, loadBundle,
>storeBundle, destroyBundle.
>
>Bundles are being stored in an HTable.
>
>We need to be able to reverse any store/destroys, should the transaction
>fail.  
>
>Let me know if this makes sense or not.
>
>Thanks,
>Matt
>
>
>--
>View this message in context:
>http://jackrabbit.510166.n4.nabble.com/NoSql-Support-tp3726565p3747262.htm
>l
>Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.


Mime
View raw message