Skip navigation links

MySQL Forums :: Custom Storage Engines :: Object Oriented Storage


Advanced Search

Re: Object Oriented Storage
Posted by: Jake Yazici ()
Date: October 13, 2005 08:03PM

Hi, Brian.

Thanks for the input. I've considered similar scenarios (i.e. serialization to blob storage), but I couldn't wrap my head around how to support locks for it in multi-user environment, especially if someone accesses a root object composed of all persisted objects. I suppose this is a problem of any native object store.

However, I have warm'n'fuzzies for the concept of wrapping the client API for a relational view. Of course, all of this implies the need to build a custom ODBC/OLEDB driver to support third-party apps that only understand those protocols.

In my research, I have found many interesting implementations and concepts for for going the other way (i.e. relational storage that provides object synthesis). Hibernate, and its .NET port, Nhibernate, are champs!

I also found that the prevalence engines were interesting (http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ). There is a .NET port of this code as well, called Bamboo.NET.

The cute feature about these prevalent systems is that data modifications are first immediately saved as atomic transactions to a transaction log. Then, the transaction log is replayed to commit changes to the live object tree. The live object tree is periodically committed to disk, and the transaction log is flushed. All objects are accessed via the prevalence interface, which just spits out the objects. I remember that there is a root prevalent object that you proxy through or request all other objects. Pretty quick'n'easy... but lacks a SQL/relational interface. Also, the engines want to keep all objects in memory… which can be prohibitive too.

Yet, to extend the prevalence engines into providing a relational interface, check this thought:
What if the transaction log could be tee-d to a daemon/service that translates the transactions from the log into common SQL which is applied to a correlated relational store? Neat! In the other direction, the daemon would be called from triggers on commits to the rdb and would be used to update the object tree based upon changes to the relational data.

Of course, again, there are issues of multiple points of failure, synchronization of relational schemas to persistent domain object model… And instead of presenting the opposite interface for a given storage type, this approach would just create two different datastores (for the same data) and keep them synchronized, which unfortunately means approximately twice the storage space needed to accommodate both. Yeaaachhh...

Options: ReplyQuote


Subject Views Written By Posted
Object Oriented Storage 12943 Jake Yazici 10/12/2005 06:39PM
Re: Object Oriented Storage 5020 Brian Aker 10/12/2005 10:25PM
Re: Object Oriented Storage 4518 Jake Yazici 10/13/2005 08:03PM
Re: Object Oriented Storage 4302 Peter Hooper 11/25/2005 09:00AM
Re: Object Oriented Storage 3681 Jake Yazici 11/03/2006 06:42AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.