[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions for Falko and Ozone gurus
At 10:56 AM 7/17/01 +0200, you wrote:
Thanks a lot Falko. I will dig into all this...
>On Mon, 16 Jul 2001, you wrote:
> > Falko (or anyone that has been deeply involved in Ozone transactions),
> >
> > I have completed the Ozone network layer documentation and will post it
> > soon. I am now into Ozone transactions, and my total inexperience in DBMS
> > implementation shows. I need help. Here's what about:
> >
> > Method calls are eventually processed by the InvokeServer and delegated to
> > the TransactionManager's handleCommand() method, which in the case of NON
> > client-demarcated transactions will call completeTransaction(), which
> > itself holds the following code:
> >
> > ...
> > if (performCommand( ta, command )) {
> > if (prepareTransaction( ta, command )) {
> > commitTransaction( ta, command );
> > }
> > }
> > ...
> >
> > I understand transactions of course (how they are associated with a server
> > thread, etc), but as an end-developper, not as a DBMS implementor!!! Is
> > there a way you (or someone else knowledgeable) could provide some
> > explanations about the life-cycle of a transaction within Ozone? How a
> > Transaction object ultimately interacts (indirectly or not) with the
> > back-end storage system during the different commit phases? What are the
> > different states of a transaction - what is their semantics? When is an
> > ObjectContainer activated/deactivated (when it is read from/persisted to
> > disk ?) ?
>
>life-cycle of a transaction:
>----------------------------
>there are two kind of transactions: long (client-demarcated) and short
>(implicit). The TransactionManager (TM) is responsible for handling them
>correct. As you correctly noted, all DbCommands (requests send from the
>client)
>are received by the InvokeManager and passed to the TM. The TM checks if the
>command is a DbTransaction command or a simple method call. In case of a
>transaction command, it does whatever the command wants it to do (create
>new tx,
>prepare, commit-one-phase, commit-two-phase, etc.). In case of a simple method
>call the TM checks if the current thread is already associated to a tx (a long
>tx). If so the TM just performs the command without doing anything about
>the tx
>(the client is responsible). If the TM does not find a tx assigned to the
>current thread than we have an ordinary method call which has to wrapped in a
>new tx, this is done by the completeTransaction() method. New transactions are
>created by the TMs newTransaction() method. This method also assignes new txs
>to the current thread. This has nothing to do with tx "joining". It is
>just the
>fact that inside the kernel each tx is assigned to one and only one thread. So
>from everywhere you can call TM.currentTransaction().
>
>tx interacting with the StoreManager (SM)
>-----------------------------------------
>Although the SM has methods like commit/abortTransaction() it knows nothing
>about transactions. It is just responsible to record all data changes (new
>container, updateLockLevel() etc.). Those changes are held inside
>TransactionData object which is associated to the tx but provided by the
>StoreManager. The transaction logic itself (when, why new/commit/abort, etc.)
>is provided by the TM.
>
>states of transactions
>----------------------
>the states shows what methods have been called for this tx already. after
>newTransaction() it has state STATUS_STARTED, while executing prepare() it is
>in STATUS_PREPARING, after completing prepare is is in STATUS_PREPARED.
>
>container activation/deactivation
>---------------------------------
>each and every operation with an database object is initiated by
>a Transaction.aquireContainer() call. This is the work horse of the system. It
>checks/sets locks, checks deadlocks, checks permissions _and_ requests the
>corresponding container from the StoreManager. Only the StoreManager is
>responsible for activating the container and/or find it in its cache and/or
>deactive other container if needed during activating another container.
>
>
> >
> > Also, if you have any links on DBMS (especially OODBMS) implementation,
> > theory, etc., post them!
>
>I did read a few books about (object) databases (maybe you can start here:
>http://www.cetus-links.org/oo_db_systems_1.html) All of them just cover one
>single aspect of databases (concurrency, persistence, objects model, etc.).
>Mostly I took just 10% from the ideas, adapt them and combine them with other
>etc. So, it should be no problem to find a book that describes basic things
>like two-phase-commit, object surrogates and things like that. But the actual
>ozone system is very unique, of course ;)
>
> >
> > Viel Dank,
>:)
>
>
>Falko
>--
>______________________________________________________________________
>Falko Braeutigam mailto:falko@smb-tec.com
>SMB GmbH http://www.smb-tec.com
>
>
>----------------------------------------------------------------------
>Post a message: mailto:ozone-dev@ozone-db.org
>Unsubscribe: mailto:ozone-dev-request@ozone-db.org?body=unsubscribe
>Contact adminstrator: mailto:ozone-dev-owner@ozone-db.org
>Read archived messages: http://www.ozone-db.org/
>----------------------------------------------------------------------
----------------------------------------------------------------------
Post a message: mailto:ozone-dev@ozone-db.org
Unsubscribe: mailto:ozone-dev-request@ozone-db.org?body=unsubscribe
Contact adminstrator: mailto:ozone-dev-owner@ozone-db.org
Read archived messages: http://www.ozone-db.org/
----------------------------------------------------------------------