Hmmm... Then I'm not sure we really want to "fix" the transaction
handling in Minerva. Let me restate the problem, and hopefully everyone
can jump in:
Minerva assumes that a connection will be closed before it is
committed or rolled back. This works great with container-demarcated
transactions, since it means the connection must be opened and closed
within one method call, which is the desired behavior. This does not
allow you to keep a Connection in an instance variable, but that's good -
it prevents a large number of connections from being locked out of the
pool.
The potential problem here is bean-demarcated transaction
handling, where the bean may open a transaction, open a connection, commit
the transaction, close the connection. This would break. If you reverse
the last two steps, it works fine.
If the connections stayed associated with the transaction, this
would be bad, since you could commit several times before closing the
connection. However, if (as Charles describes below) the transaction ends
when you commit, then the problem code above would leave your connection
open with no transaction associated, which would definitely be bad - so
maybe it's OK to throw an exception in this case. Kind of heavy-handed,
but it closes a big potential problem.
How do you people feel? I think we're helping people in the long
run if we leave things like they are.
Now, here's a related question. If you open a connection, *then*
start a transaction, the connection is not associated with the
transaction. That is also bad (and probably not what you intended), but I
don't see anything we can do about it - other than maybe throwing an
exception in executeUpdate if you're using the XA wrapper and there's no
current transaction.
Aaron
On Tue, 19 Sep 2000, Charles Crain wrote:
> Once you commit/rollback, the transaction is gone. Any more work you do will
> be out of transactional scope until you call begin() again. As far as how
> long they may be associated, transactions have a timeout that is
> user-specified (in one of the xml files, I forget if it is ejb-jar or jboss),
> after which they will effectively auto-rollback. The timeout is implemented
> via some classes in org/jboss/util.
>
> -Charles
