geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Pessimistic locking strategy for CMP beans in 1.1.1
Date Mon, 31 Jul 2006 16:58:34 GMT
I'm not sure this will cover the common strategies used by most  
containers.  I recall implementing a few different strategies in  
another appserver:

o DB auto update sequence
o Container manual update sequence
o DB last modified timestamp column
o Container manual update sequence (unreliable but people use it)
o Check column values haven't changed between select an update
    o All columns
    o Some special columns
    o Only columns being updated
    o All columns that were read in during the tx

I doubt we need all of these, but I think we should allow room for  
growth in the schema.


On Jul 31, 2006, at 7:38 AM, Matt Hogstrom wrote:

> Perhaps one additional element in the optimistic section like:
>   <concurrency-control>[DATABASE | CONTAINER]</concurrency-control>
> Dain Sundstrom wrote:
>> +1 looks good
>> On Jul 26, 2006, at 7:47 PM, Matt Hogstrom wrote:
>>>           <locking-strategy>
>>>               <optimistic-locking>
>>>                 <optimistic-column>occColumn</optimistic-column>
>>>                 <optimistic-type>TIMESTAMP</optimistic-type>
>>>           </locking-strategy>
>> one comment... this xml implies that the database is handling the  
>> auto increment/update of the optimistic lock column.  I have seen  
>> schemas that assume that the application code will be handling  
>> this, with some sql like this:
>> UPDATE foo
>> SET value = newValue, ver = 5
>> WHERE pk = myPk AND ver = 4
>> If the database is auto updating the row, you will need to reread  
>> the column after any update, so if you make another update in the  
>> same transaction, you can assure you know the current value of the  
>> optimistic column.
>> -dain

View raw message