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 Thu, 18 Aug 2011 12:56:59 GMT

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

>I was going to start looking into this project the next iteration.
Have a look at this as well https://github.com/drevell/megalon
I also have some ideas (based on the megastore/Google App Engine store)
applicable directly to the JCR hierarchical structure. These are in fact
what led me to this.

>Getting this working is pretty much not an option for me :)  At that
>my impl would probably be considered a rogue project.
>The only other options I see are storing operations and serialized bundles
>in memory for rollback(extremely dangerous).  Or writing the operations
>serialized bundles out to the file system(extremely ugly).
>I'd be extremely nervous about storing the operations within hbase itself.
Why is that?

>If you check out the BundleDbPersistenceManager and figure out a clean way
>to do transaction management, please let me know!
I will. And as I said there could be a few options if multi row
transactions are required (again Google has some papers on this)

Eventually an Hbase backed JCR should be both scalable and with higher


>>Thanks Jukka, 
>>Depending on the data layout different solutions are possible.
>>If there's a finite depth of the tree than one or more final levels
>>be encoded in a single row. There's virtually an infinite number of
>>columns you could have on a single row (by default limited to 250MB)
>>If more than one row needs update an optimistic locking mechanism could
>>Again, it depends on the constraints (tree depth, nodes per level
>View this message in context:
>Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

View raw message