[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions for Falko and Ozone gurus
At 09:53 AM 7/18/01 +0200, you wrote:
I agree with making the docs available (better than nothing). Does anyone
think it is unproper yet? If not, let's proceed.
Yanick
>On Tue, 17 Jul 2001, you wrote:
> > At 10:56 AM 7/17/01 +0200, you wrote:
> >
> > Thanks a lot Falko. I will dig into all this...
>
>Great. Thanks, Yanick. I really love your work so far :) Do you, and the
>rest of
>the doc team, think it would make sense to make the unfinished/uncomplete docs
>available to the public? IMO they are already useful as they are. Well,
>for sure
>better than nothing and right now we do have nothing like your dev guide
>available.
>
>Forgot one thing about tx states: the state of a tx can only be raised. So,
>after STATUS_STARTED it can only be prepared/committed/aborted - after prepare
>it can only be committed or aborted. Well, maybe not that important - just for
>the records ;)
>
>
>Falko
>
> >
> > >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/
> > ----------------------------------------------------------------------
>--
>______________________________________________________________________
>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/
----------------------------------------------------------------------