On 2001.06.11 23:57:00 -0400 Georg Rehfeld wrote:
> 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).
I suppose versioning could be done in the db with an update trigger and
sequence(oracle)/generator(firebird/interbase). It seems like this is
getting complicated...
>
>
> 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.
One place I saw it is in Borland Delphi, in which there are 3 cached update
concurrency options,
pk only, changed fields only (+ pk) and all fields.
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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
