My feeling on that is that anything goes with client- and bean-demarcated
transactions. Let's for a second (to simplify things) imagine Minerva doesn't
exist (no offense Aaron) and say we are just connecting to JDBC directly. I can
certainly envision starting a transaction, doing some work, committing it, then
doing some work outside a transaction (probably some queries), then opening a
second transaction, do some work, then roll it back or commit it. The issue of
committing after closing a direct JDBC connection doesn't apply of course, because
you can't do that.
If possible, this sort of thing should be allowed by Minerva in my opinion. I
agree with Aaron that it's probably tighter design on the part of the bean
programmer not to be doing all kinds of junk like this, but the spec does allow for
it.
I don't think it's in anyway a huge deal if we don't support this, if it is a
difficult fix. However, if we decide not to support it, we should be very explicit
about it, such that if a user gets an error due to this non-standard behavior on
our part.
-Charles
Aaron Mulder wrote:
> 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
