non-persistant objects vs transaction

[Alexander Larsson <alexl redhat com>]

We currently have some issues with transactions and the border between
persistant and non-persistant object. Take for instance
Topic.closeComment(). It creates a new (persistant) ClosedComment
object, adds it to the topic, and then removes/destroys the
(non-persistant) LiveComment. 

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.

There is a pretty easy fix for this issue:

diff -u -p -r1.46 ActiveTopic.java
--- src/org/gnome/yarrr/ActiveTopic.java        28 Apr 2005 12:23:11 -0000      1.46
+++ src/org/gnome/yarrr/ActiveTopic.java        29 Apr 2005 09:10:40 -0000
@@ -50,6 +50,7 @@ public class ActiveTopic extends Topleve
                ClosedComment comment = new ClosedComment(this.getTopic(), closer, livecomment.getText(), allAuthors, msgs);
         addMonitor(comment);
                this.getTopic().addClosedComment(comment);
+        HibernateUtil.commitTransaction();
         discussion.removeComment(livecomment, closer);
                this.signalChanged();
                return comment;


I.e. We make sure the transaction finishes (if it doesn't it'll throw an
exception) before we remove the LiveComment.

However, this complicates how we use transactions, and how various calls
like this can be used together in a transaction. I'm not sure there are
any other ways though. Any ideas?


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fast talking moralistic dwarf looking for 'the Big One.' She's a 
brilliant communist stripper prone to fits of savage, blood-crazed rage. They 
fight crime!