Hi Michael,
The problem is that there is no way for a bulk update to do a version
check on the objects affected by the operation. The objects are
never returned and the version numbers of objects that may or may not
have been in memory are not necessarily the same and could not all be
checked in a bulk operation.
Updating the column is easily achieved by the query itself if that is
what the client is trying to achieve, but the rationale was that the
provider should probably not blindly go ahead and do the update and
appear to be doing the checking if it can only ever do the updating part.
Two badly timed bulk updates would still be able to munge each others
changes.
Hope this clarifies things a bit.
-Mike
> -----Original Message-----
> From: Michael Bouschen [mailto:Michael.Bouschen_at_Sun.COM]
> Sent: Monday, January 16, 2006 9:33 AM
> To: Linda DeMichiel; Mike Keith
> Cc: persistence_at_glassfish.dev.java.net
> Subject: EJBQL bulk UPDATE statement should not update version columns
>
>
> Hi Linda, hi Mike,
>
> the PFD version of the spec clarifies the behavior of an EJBQL bulk
> UPDATE statement wrt. to version columns: "Bulk update maps
> directly to
> a database update operation, bypassing optimistic locking checks. The
> application must manually update the value of the version column, if
> desired, and/or manually validate the value of the version column."
>
> I'm wondering why the bulk UPDATE does not update the version column,
> because then these changes get lost if a parallel transaction modifies
> the same instances. W/o updating the version column none of the
> transactions is able to detect the conflict. Could you please
> give some
> details about the rationale?
>
> Thanks!
>
> Regards Michael
>
>