Hi David and Bill,
David Jencks wrote:
> I like your idea for optimistic locking, however I think generally you
need
> to check that -no- fields have been changed, not just the ones you
changed.
> These are two different behaviors, sometimes you want one and sometimes
> the other, but I think as a default you are more likely to want the -no-
> fields changed option. This is more like what versioning db's such as
> interbase/firebird do.
May be you are right, the 'no fields changed' option will be
required sometimes or most, but then, my suggestion even allows
several clients to modify concurrently as long as they modify
different fields (and don't deadlock while the DB holds write
locks between update and commit, I said already, this only
'mimickes', but is no true optimistic locking).
Besides, the timestamp variant would resemble to the 'no fields
changed' behaviour with a shorter WHERE clause, but requires an
additional field in the DB (and might lead to 'race condition'
problems when 2 clients read and update within the same millisecond,
could be solved by versioning instead of timestamping).
Bill Burke said:
> Really cool stuff! This can be easily implemented in CMP/JAWS
> since JAWS keeps the old state alive.
Thanks, but it's not my idea, have seen it elsewhere I can't
remember just now. If one currently would implement that for
CMP/JAWS it would be of no big use for the average user of JBoss
running only one JBoss instance, since the container does lock
before the SQL is executing. Users of multiple JBoss instances
working on the same DB may benefit from it a little bit, when the
concurrent access is distributed to different JBoss instances.
But when the 'rabbit' comes back to the surface in a few days
having 'multiple instances' hobbeling after him it might come
in handy to give them some 'food' to eat.
So I would take the implementation of the mimicked optimistic
locking behaviour in JAWS, respecting both, the 'no fields changed'
and the more concurrent option [ignoring timestamping/versioning for
now] (also to continue my just established write access to CVS :-)
If the maintainers of JAWS (or any others) think, I shouldn't do
that, please tell me.
my very best regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
PS: don't expect me to be very quick, I've to look at a lot of
new stuff and my boss asks for some attention too.
PS2: I'll certainly need some advice with the CVS version to
code/commit against, I think it should make it into the
'RabbitHole' and the 'Branch_2_2'? Please to my gmx account to
not clutter the list (except you think, the explanation will
help others too).
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
