[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 uploaded 2 images that are part of the doc to CVS. Make sure you use the
latest build.xml (updated by Eric) so the images are properly copied from
src to build. You should see the images in the resulting html. I think this
whole thing will provide a satisfactory doc for now - but a warning on the
web site saying that it is a draft will be appropriate...
Cheers,
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/
----------------------------------------------------------------------