Re: non-persistant objects vs transaction

[Colin Walters <walters redhat com>]

On Fri, 2005-04-29 at 11:14 +0200, Alexander Larsson wrote:

> However, the ClosedComment changes are not commited until the
> transaction is commited, which is normally at the end of the xmlrpc
> call. If the transaction fails (for instance due to the oportunistc
> locking with versioning that walters just added) we'll loose the
> LiveComment, but not get a ClosedComment.

Right.  I added the optimistic locking because I thought there would be
a conflict where two people simultaneously proponent a ClosedComment.  I
started refactoring the code so we could have an XML-RPC method note
that it wanted to control the transaction itself.  Simultaneously I was
writing a test case
(YarrrRemoteTests.testRemoteClosedCommentSimultaenousProponent)
that I expected to fail.  However, it passed!

The reason is due to the way we're Hibernate maps the Set of proponents
to SQL.  Adding to it doesn't actually dirty the ClosedComment object,
since it's mapped as a separate database table.  Thus, you can't get
conflicts with two people adding to it.

Since in fact "proponenting" is the only way of modifying a closed
comment, AFAICS we simply cannot get StateObjectStateExceptions (i.e.
conflicts) here.  We could get database failures of course though, but
recovery in that situation is problematic.  I guess it'd be nice though
not to have the live comment disappear so people can at least copy and
paste it.