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.
-dain
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
