8 p.m.
I decided on a slight conceptual change. I moved the ResourceRegistry
inside the LogicalConnection. I also moved the logic for acquiring and
releasing connections inside the LogicalConnection based on certain
callbacks I added to LogicalConnectionImplementor (previously the
JdbcSession managed the release calls on the LogicalConnection). This
allowed me to (imo) clean up the "resource clean up" logic.
I also added the notion of ConnectionAcquisitionMode as an alternative
means of the underlying problem that ConnectionReleaseMode addressed.
The idea here is to request that Connections be acquired aggressively
(as opposed to lazily) and not released until the (Jdbc)Session closes.
I also added quite a few code comments, as well as log statements to
help "visualize" the call stack
All these mentioned changes have been made in the org.hibernate.resource
package. The only real divergence between org.hibernate.resource and
org.hibernate.resource2 in the "other discussion" wrt the type of API to
expose for performing "JDBC operations". I want to nail down this
lower-level resource handling first. Then I can apply these changes to
both and use 2 packages to illustrate the different granularity proposals.
On 12/07/2013 10:31 AM, Steve Ebersole wrote:
I tend to agree...
On Dec 7, 2013 10:23 AM, "Scott Marlow" <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 12/06/2013 04:45 PM, Scott Marlow wrote:
I think this is an excellent question, my preference is to
fail-fast in
some fashion.
JTA 1.1 spec description of Transaction.setRollbackOnly():
"
public void setRollbackOnly() throws IllegalStateException,
SystemException
Modify the transaction associated with the target object such
that the
only possible outcome of the transaction is to roll back the
transaction.
"
From an EJB point of view, the EJB container will eventually
notice
that the transaction is marked for rollback only when the EJB bean
invocation completes but its not clear (to me) what this means
at the
JPA level.
Might be worth asking the JBossTS team, this question.
I believe that a future EE or JPA expert group will discuss
whether applications can expect a transaction to fail-fast in the
JPA persistence provider. The discussion about this came up as
part of a TCK issue (CTS-182 related whatever that is ;)
I'm in favor of fail-fast as soon as possible, so that the
application doesn't spend (potentially), hours before attempting
to commit the JTA transaction, only to then realize that it is
marked rollback only. This doesn't seem that much different than
detecting that the active JTA transaction has timed out.
On 12/06/2013 03:38 PM, Steve Ebersole wrote:
The bigger question is whether we care. Is there really a
benefit to
continuing work when a transaction is marked for rollback
only?
On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
Hi Steve,
Looking at the Javadoc for
javax.transaction.Transaction.registerSynchronization(Synchronization
sync), I see:
Throws: RollbackException - Thrown to indicate that
the transaction has been marked for rollback only.
That would make it a JTA spec requirement.
More feedback coming...
----- Original Message -----
From: "Steve Ebersole" <steve(a)hibernate.org
<mailto:steve@hibernate.org>>
To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>>
Sent: Friday, December 6, 2013 10:07:22 AM
Subject: Re: [hibernate-dev] JdbcSession proposal
So I'll get the ball rolling :) Here is one thing
in particular I was
hoping to start a discussion on...
For JTA transactions we currently have a lot of
complex logic to manage
who "drives" the transaction flow into Hibernate
(in terms of Hibernate
reacting to the completion). There are
potentially 2 drivers:
1) A JTA Synchronization registered with the JTA
system
2) The org.hibernate.Transaction instance
A lot of the complexity in our current code comes
from the fact that we
have a lot of attempting to handle cases in which
the JTA
Synchronization cannot be registered. So one of
the simplifications I
am wanting to make here is to say that the driver
will always be the
JTA Synchronization. So I am trying to determine
how "actual" these
cases where the "JTA Synchronization cannot be
registered" are.
The only one that I am aware of IIRC is that JTA
Synchronization cannot
be registered on transactions that are marked for
rollback-only. I
cannot remember though if that was a specific
provider (JBossTS?) or a
JTA/JTS spec requirement.
So the proposal I have is that for JTA cases we
always register the JTA
Synchronization and allow that to drive the
"before/after completion"
callbacks (the org.hibernate.Transaction would
still potentially manage
actually calling commit/rollback on the
TransactionManager/UserTransaction). In short,
does any one see
problems with this approach?
On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole
wrote:
I found a few spare minutes to work on this a
little and move it into
the next stage with some actual interfaces,
impls and usages to help
illustrate some of the proposed concepts.
https://github.com/sebersole/JdbcSession
The README.md is very up-to-date and detailed.
Would be good to get
input from others.
P.S. I probably dislike the *Inflow naming
more than you do :)
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev