On 8/17/11 4:35 PM, "matthew.l.donnelly" <[email protected]> wrote:
>Cosmin, > >I was going to start looking into this project the next iteration. >https://github.com/hbase-trx 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 >point, >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 >and >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 Performance. Cosmin > >Thanks, >Matt > >>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 >>could >>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 >>be >>employed. > > >>Again, it depends on the constraints (tree depth, nodes per level >>number, >>etc.) > >>Cosmin > >-- >View this message in context: >http://jackrabbit.510166.n4.nabble.com/NoSql-Support-tp3726565p3749984.htm >l >Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
