[hibernate-dev] JdbcSession proposal
Brett Meyer
brmeyer at redhat.com
Mon Jan 6 15:48:51 EST 2014
Apologies for being late to the party. Thoughts:
* As discussed with Steve on IRC today, one big pain point has been that resource management/cleanup currently involves JdbcCoordinatorImpl#xref. It maps ResultSets to a Statement instance. This was great with the old proxy system, but now needs to go away. If a JDBC driver eventually wraps the given Statement with its own impl (several do it), the keying fails and the ResultSet cleanup never happens. Scoping JDBC resources to the Operation, then closing them as soon as we're finished with them (assuming holdOpenResources == false), would mitigate this.
* +1 for the "Operation API", over the granular set of boilerplate code. Also, imo, I'd overload the API methods with the specific Operation impl arguments (ex: #accept(PreparedStatementQueryOperation)), rather than only one (ex: #accept(Operation)). I tend to think it's cleaner, removing type checks, etc. I know there was already some debate about that, so just my $.02.
* If you haven't already, define default Operation impls and use wherever possible?
* There was some discussion comparing the difficulty of integrating each possibility into ORM. Imo, *any* of them will be difficult. Removing the proxy system was a gigantic, tedious pain. That being said, let's make sure we identify all possible future needs, including the applicability of DataStoreSession, and do them once. I'd hate to roll with something, then have to change/extend it later on. The proposal process has already been doing this, but it's worth mentioning.
* Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS?
* Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast. But, just want to make sure we're not overlooking something.
* How would CMT fit into this?
* +1 for using "transaction driving" and "transaction reacting" terms, over "in/out flow"
That's just from a preliminary look -- I'll go through the code in more detail when I can.
Brett Meyer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Steve Ebersole" <steve at hibernate.org>
To: "Scott Marlow" <smarlow at redhat.com>
Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Monday, December 9, 2013 2:00:38 PM
Subject: Re: [hibernate-dev] JdbcSession proposal
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 at redhat.com
> <mailto:smarlow at 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 at hibernate.org
> <mailto:steve at hibernate.org>>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at 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 at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
More information about the hibernate-dev
mailing list