Ahh yes, I see your point. However, keep in mind that if you are just
making
JDBC calls (not using JTA or anything), you can do multiple transactions
for
one connection like this:
jdbcConn.setAutoCommit(false);
jdbcConn.doSomeStuff();
jdbcConn.doSomeMoreStuff();
jdbcConn.commit();
jdbcConn.doSomeStuff();
jdbcConn.doSomeMoreStuff();
jdbcConn.rollback();
jdbcConn.setAutoCommit(true);
jdbcConn.doSomeStuffOutsideTransaction();
jdbcConn.setAutoCommit(false);
jdbcConn.inTheTransactionAgain();
...
Actually, looking at the above, I see I may have answered your first
question
somewhat misleadingly (the one about transactions going away when you
commit()). The semantics of UserTransaction say that yes, a transaction
goes
away when you commit() or rollback() it. After a call to either of
these
methods, you are now operating outside a transaction.
HOWEVER, in JDBC, the semantics are different, since there is no call to
begin(). When you call setAutoCommit(false), that means that ALL
FURTHER
CALLS on that connection are in a transactional scope. A call to
commit() or
rollback() ends the first transaction and immediately starts a new one.
The
only way to get out of transactional scope is to say
setAutoCommit(true).
So one has the difficult task of mapping the UserTransaction semantics
(begin(), commit()/rollback()) to JDBC semantics (setAutoCommit(false),
commit()/rollback(), setAutoCommit(true)). However, I see the problem
of
beginning a transaction on an already open connection. That would
somehow
require propagating the call to UserTransaction::begin() all the way
down to
the already-open JDBC connection, which would cause a call to
setAutoCommit(false). I haven't look at this portion of the code, so I
don't
know what is involved...I assume there will be some fooling with the XA
classes.
Let me know what you think.
-Charles
Aaron Mulder wrote:
> On Tue, 19 Sep 2000, Charles Crain wrote:
> > 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.
>
> You can't do this in a transactional environment, as far as I can
> tell. Let's say you open a transaction, open a connection, do some work,
> commit. Now the transaction is gone. Do some queries, open another
> transaction. Your existing connection is not associated with that new
> transaction. There is, as far as I can tell, no way for you to tell a
> transaction that you want it to associate with an existing connection
> (javax.transaction.UserTransaction seems pretty bare). And the server
> can't do it automatically, because you could create three new
> transactions, and then which one would it pick?
> So the only way for you to do this is to get a second connection
> after you started the second transaction, and then is there a compelling
> reason not to do it the way I proposed?
>
> Aaron
>
> >
> > 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
