db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Warnock <da...@sundayta.com>
Subject Optimistic Locking change
Date Thu, 20 Mar 2003 21:26:50 GMT
Hi,

On the user list I asked about a potential change to the way optimistic 
locking works. Thomas was positive about the idea so I have explored it 
a bit further.

Proposal.

1. Use the locking="true" attribute of field-descriptor in the 
repository for optimistic locking. This optimistic locking is to 
validate that no other user has changed a row (by checking for no change 
in either a timestamp or integer version column).

2. Add an updatelock="true|false" attribute to field-descriptor. If both 
locking and updatelockcolumn are true then the behaviour will be as now 
(ie OJB will update the lock column whenever it saves). Otherwise the 
updatelock will be left to the database to handle using triggers.

updatelock will default to true which will mean the default  behaviour 
will be unchanged from the present.

Currently the locking is overloaded as it is used for 2 purposes, check 
the lock columns have not changed, cause the lockcolumns to be updated. 
This proposal separates out these needs.

To implement this change the following needs to be done.

repository.dtd
==============

Add to field-descriptor

	updatelock (true | false) "true"

FieldDescriptor.java
====================

Add
     private boolean updatelock = false;

Add (NB Javadoc cut to keep email short)
     public boolean isUpdatelock()
     {
         return updatelock;
     }

     public void setUpdatelock(boolean updatelock)
     {
         this.updatelock = updatelock;
     }

Modify toXml
         if (!this.isUpdatelock())
         {
             result += "        " + tags.getAttribute(UPDATELOCK, 
"false") + eol;
         }

ClassDescriptor.java
====================

Modify UpdateLockingValues so that fields where updatelock is false are 
not changed.

insert line at 721:
	if (fmd.isUpdatelock()) {

insert close block after current line 755:
	}


Would a patch to make these changes be acceptable?

I am a little less confident of changing the existing tests as I don't 
what to muck about with the hypersonic db.

Thanks

Dave
-- 
David Warnock, Sundayta Ltd. http://www.sundayta.com
iDocSys for Document Management. VisibleResults for Fundraising.
Development and Hosting of Web Applications and Sites.



Mime
View raw message