Jeff, thanks for looking into this...
while you're at it, I posted this as a bug to the "wishlist" site, but
it didn't make it into 2.0.1... I've taken to building the
HibernateAssembler myself to try to get things working, but this is
dedfinitely a defect:
HibernateAssembler.java (fds2.0.1 release version)
Line (starting): 691
int k;
for (k = i; k < toList.size(); k++)
{
if (assocType.getIdentityFromItem(toList.get(i)).equals(fromId))
break;
}
Notice that the index used in the loop is (i) not (k)... this was
causing some really odd behavior that took me a good while to figure
out =)
thanks again,
PW
--- In [email protected], "Jeff Vroom" <[EMAIL PROTECTED]> wrote:
>
> My apologies - this does look like a bug. I need to do more testing on
> this case myself, but I think one of the big problems here is that we
> are trying to do conflict detection on our own in the hibernate
> assembler's updateItem method. Unless you are using a strict isolation
> level in your DB (repeatable read or serializable) this is not going to
> be transactionally correct anyway since the DB version can be modified
> after we have executed the query and before we do our update. We
> probably should not be getting the server version at all... hibernate
> has its own optimistic concurrency support that we should be using if it
> is enabled. That is probably the only way to get atomic conflict
> detection without resorting to using those particularly slow isolation
> levels.
>
>
>
> That would potentially get rid of the conflicting version of the item in
> the transaction. The other thing I need to look into is the "merge"
> method in hibernate. Seems like we should probably be using that in the
> updateItem method? I'll be working on this next week so will send out
> any updates I can to the code.
>
>
>
> Jeff
>
