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
