I personally think option 2 sounds just fine, though I admit I have no idea what
the EJB spec has to say on the matter. However for my part, I can't think of any
"real" situations that would break if we went with option 2.
-Charles
Aaron Mulder wrote:
> I would not say that setAutoCommit(true) removes you from the
> context of a transaction. You'll get a new transaction for every action,
> and they're committed without your intervention. That is, if you're in
> *no* transaction, and you do some work, and then close your client and
> restart the DB, the state of the data is not well defined (to my
> knowledge). Some DBs may commit, some may roll back, some may just
> complain. If you turn on auto-commit, the behavior is different - it
> behaves exactly like there's a new transaction for every statement and you
> commit after every statement, so any work you do is guaranteed to be
> applied - see what I mean?
> Now, I agree that the behavior is different between JDBC 1/2 and
> the JSBC 2 Optional Package. But everyone who's using EJBs kind of has
> the Optional Package behavior thrust upon them, so that's the problem we
> need to solve.
>
> So, the server code required to attach a new transaction to an
> old connection is fairly straightforward. But I don't believe we can
> determine *when to do that*. I don't believe that every DB connection
> that is not part of a transaction should be attached whenever a new
> transaction is started. Even if we tried to map connections to threads or
> something, I don't believe that every DB connection used in one particular
> place should be automatically attached to a transaction when a new
> transactions is started. Isn't the whole point of client/bean-demarcated
> transactions that the developer handles the mechanics of the transaction,
> so shouldn't they be the one to decide which connections go with which
> transactions?
> Unfortunately, there is no way for the developer to do
> that. Though the server code is trivial, the bean code is not possible -
> not without excessive casting and digging through internal server clases,
> which would be a *major* no-no. There are no methods of Connection or
> UserTransaction or Transaction that would allow a developer to make this
> association.
> So, it seems to be we have 3 options:
>
> 1) Force all connections to be associated with a new transaction, so the
> only way to have a connection associated with no transaction is to have no
> transaction.
>
> 2) Force you to open and close a connection within opening and closing a
> transaction to associate them, and open a connection outside opening and
> closing a transaction to use a connection associated with no transaction.
>
> 3) If you open a connection between opening and closing a transaction, it
> is associated with the transaction until the transaction is committed or
> rolled back; thereafter it is associated with no transaction until it is
> closed. If you open a connection before opening a transaction, it is
> always associated with no transaction.
>
> I prefer option 2, because you have flexibility on whether your
> connections are associated with a transaction or not, and consistency in
> that a conneciton is either associated or not, but does not change over
> its lifetime.
>
> Aaron
