db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Nitz ...@ukr.net>
Subject [PFE] locking via database for multi-VM environment
Date Sat, 20 Dec 2003 17:56:08 GMT
Hi All,

I thought it's time to add this feature to OTM (only in-memory locks is 
implemented in OTM for now), so I looked at how it is implemented in ODMG. 
Correct me if I'm wrong but here is what I see: 
1) every lock entry = {object id, tx id, lock type} is represented by one 
database record, different records for different transactions
2) all database operations on lock entries are performed in bounds of the 
current ODMG transaction
This means that:
1) two VMs can check that currently there is no write lock and then 
simultaneously add two write locks represented by two different records.
Since databases is usually configured to lock rows or pages rather then whole 
table, this illegal operation of adding two write locks for the same object 
may succeed.
2) when one VM puts some lock on object, it is not seen by other VMs until 
the commit of the current database transaction (if database isolation is at 
least READ_COMMITED, usually it is true). Thus at the time when lock is 
necessary nobody see it. Then after 
   getBroker().commitTransaction();
all locks are removed from the database, but this action is done in the next 
database transaction so all objects remain locked until the end of the NEXT 
transaction, so everybody see that the object is locked at the time when it 
is not.

I will be happy if you point me at a mistake in the above reasoning.

Below is what I propose for OTM locking via database (ODMG will use OTM in the 
future, so I think it doesn't make sense to change ODMG now)
1) Locks should be represented by one record per one locked object.
Such record should contain 
- object ID 
- ID of VM holding write lock and 
- IDs for VMs that hold read locks 
This means that the total number of VMs is limited by the number of fields for 
reader's IDs, but we can make this limit configurable. It is limited by 
the number of columns allowed by RDBMS. I think this is acceptable way.
2) All changes of lock records should be done in own "short" database 
transactions, using own independent PersistenceBroker: 
read the lock record, change it, write to database, commit. 
IMO this will guarantee correct behavior in all cases (if database isolation 
is at least READ_COMMITED).

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message