[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions for Falko and Ozone gurus
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/
----------------------------------------------------------------------