Today porting some benchmark code to Hibernate ORM 5.2 I had several difficulties around the fact that the code now needs to be different depending on transactions being container managed or not. My goal was to have a single benchmark test which I could compile once and run in either JavaSE or CMT; with some help from Steve I figured the necessary incantations out but ... it looks very unpractical. One way is to use an isolation delegate, which looks like this: final SessionImplementor session = (SessionImplementor) s; session.getTransactionCoordinator().createIsolationDelegate().delegateWork( new WorkExecutorVisitable() { @ Override public Object accept(WorkExecutor executor, Connection connection) throws SQLException { /// Some work with PreparedStatement on Connection.. } }, true ); This worked fine for some raw SQL used for the benchmark initialization, but in another case I'd prefer to use the Session API rather than dealing with PreparedStatements and native connections; it looks like we don't have an equivalent "run code in isolation" for the Session ? It would be great if I could just pass a lambda to a Session and have this executed on a "child Session" in the scope of a "child Transaction", or just start and commit a transaction if there isn't one. s.executeInIsolation( session -> session.save(...) ); So I'd expect that details like how to begin the transaction, how it should be committed (or rolled back in case of exceptions), how to lookup a TransactionManager, and especially how to not leak resources should be handled for the user. Obviously the inner Session instance is a different one than the outer, so any data returned by this block should be considered detached; maybe this limitation would be clearer if the method was hosted on SessionFactory or StatelessSession instead? Although it wouldn't necessarily have the limitations of a StalessSession, and it would be nice to have the inner transaction behave as a nested one when there's already one in the host Session. Looking forward for comments and improvement ideas :) Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 14 September 2016 at 20:32, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > The problem with "execute in isolation" here is that the "isolation" aspect > refers to being isolated from any current transaction. It says nothing > about whether that stuff-to-execute should itself be transacted. This is > why, for example, you see IsolationDelegate accept a `transacted` boolean > argument. > > How would you propose we pass such a flag in this case? Or are you > proposing that this always start a (new) transaction? I had only the (new) transaction case in mind, but sure you could add a `transacted` boolean parameter. Or we make it explicit with a better method name: s.executeInSubtransaction( session -> session.save(...) ); Thanks, Sanne > > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several >> difficulties around the fact that the code now needs to be different >> depending on transactions being container managed or not. >> >> My goal was to have a single benchmark test which I could compile once >> and run in either JavaSE or CMT; with some help from Steve I figured >> the necessary incantations out but ... it looks very unpractical. >> >> One way is to use an isolation delegate, which looks like this: >> >> final SessionImplementor session = (SessionImplementor) s; >> >> session.getTransactionCoordinator().createIsolationDelegate().delegateWork( >> new WorkExecutorVisitable() { >> @ Override >> public Object accept(WorkExecutor executor, Connection >> connection) throws SQLException { >> /// Some work with PreparedStatement on Connection.. >> } >> }, true ); >> >> This worked fine for some raw SQL used for the benchmark >> initialization, but in another case I'd prefer to use the Session API >> rather than dealing with PreparedStatements and native connections; >> it looks like we don't have an equivalent "run code in isolation" for >> the Session ? >> >> It would be great if I could just pass a lambda to a Session and have >> this executed on a "child Session" in the scope of a "child >> Transaction", or just start and commit a transaction if there isn't >> one. >> >> s.executeInIsolation( session -> session.save(...) ); >> >> So I'd expect that details like how to begin the transaction, how it >> should be committed (or rolled back in case of exceptions), how to >> lookup a TransactionManager, and especially how to not leak resources >> should be handled for the user. >> >> Obviously the inner Session instance is a different one than the >> outer, so any data returned by this block should be considered >> detached; maybe this limitation would be clearer if the method was >> hosted on SessionFactory or StatelessSession instead? >> Although it wouldn't necessarily have the limitations of a >> StalessSession, and it would be nice to have the inner transaction >> behave as a nested one when there's already one in the host Session. >> >> Looking forward for comments and improvement ideas :) >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

Also, why do you keep defining this in terms of Session, rather than SessionFactory?

On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > "Better" according to whom? ;) > > I personally very much dislike the kind of API explosion this kind of > thing leads to. > > > On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: >> >> On 14 September 2016 at 20:32, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> > The problem with "execute in isolation" here is that the "isolation" >> > aspect >> > refers to being isolated from any current transaction. It says nothing >> > about whether that stuff-to-execute should itself be transacted. This >> > is >> > why, for example, you see IsolationDelegate accept a `transacted` >> > boolean >> > argument. >> > >> > How would you propose we pass such a flag in this case? Or are you >> > proposing that this always start a (new) transaction? >> >> I had only the (new) transaction case in mind, but sure you could add >> a `transacted` boolean parameter. >> >> Or we make it explicit with a better method name: >> >> s.executeInSubtransaction( session -> session.save(...) ); >> >> Thanks, >> Sanne >> >> >> > >> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne(a)hibernate.org&gt; >> > wrote: >> >> >> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several >> >> difficulties around the fact that the code now needs to be different >> >> depending on transactions being container managed or not. >> >> >> >> My goal was to have a single benchmark test which I could compile once >> >> and run in either JavaSE or CMT; with some help from Steve I figured >> >> the necessary incantations out but ... it looks very unpractical. >> >> >> >> One way is to use an isolation delegate, which looks like this: >> >> >> >> final SessionImplementor session = (SessionImplementor) s; >> >> >> >> >> >> session.getTransactionCoordinator().createIsolationDelegate().delegateWork( >> >> new WorkExecutorVisitable() { >> >> @ Override >> >> public Object accept(WorkExecutor executor, Connection >> >> connection) throws SQLException { >> >> /// Some work with PreparedStatement on Connection.. >> >> } >> >> }, true ); >> >> >> >> This worked fine for some raw SQL used for the benchmark >> >> initialization, but in another case I'd prefer to use the Session API >> >> rather than dealing with PreparedStatements and native connections; >> >> it looks like we don't have an equivalent "run code in isolation" for >> >> the Session ? >> >> >> >> It would be great if I could just pass a lambda to a Session and have >> >> this executed on a "child Session" in the scope of a "child >> >> Transaction", or just start and commit a transaction if there isn't >> >> one. >> >> >> >> s.executeInIsolation( session -> session.save(...) ); >> >> >> >> So I'd expect that details like how to begin the transaction, how it >> >> should be committed (or rolled back in case of exceptions), how to >> >> lookup a TransactionManager, and especially how to not leak resources >> >> should be handled for the user. >> >> >> >> Obviously the inner Session instance is a different one than the >> >> outer, so any data returned by this block should be considered >> >> detached; maybe this limitation would be clearer if the method was >> >> hosted on SessionFactory or StatelessSession instead? >> >> Although it wouldn't necessarily have the limitations of a >> >> StalessSession, and it would be nice to have the inner transaction >> >> behave as a nested one when there's already one in the host Session. >> >> >> >> Looking forward for comments and improvement ideas :) >> >> >> >> Thanks, >> >> Sanne >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

Most transaction systems do not support nested transactions On Wed, Sep 14, 2016 at 3:13 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 14 September 2016 at 21:02, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > Also, why do you keep defining this in terms of Session, rather than > > SessionFactory? > > I mentioned that same doubt in my first email of this thread. > I think I prefer Session as that's what people interact with most of > the time, and it's a better choice if we opt to make this a nested > transaction of the current one; if it's meant to be totally > independent yes then we should probably consider the SF. > > > > > > > On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> > >> "Better" according to whom? ;) > >> > >> I personally very much dislike the kind of API explosion this kind of > >> thing leads to. > >> > >> > >> On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne(a)hibernate.org&gt; > >> wrote: > >>> > >>> On 14 September 2016 at 20:32, Steve Ebersole <steve(a)hibernate.org&gt; > >>> wrote: > >>> > The problem with "execute in isolation" here is that the "isolation" > >>> > aspect > >>> > refers to being isolated from any current transaction. It says > nothing > >>> > about whether that stuff-to-execute should itself be transacted. > This > >>> > is > >>> > why, for example, you see IsolationDelegate accept a `transacted` > >>> > boolean > >>> > argument. > >>> > > >>> > How would you propose we pass such a flag in this case? Or are you > >>> > proposing that this always start a (new) transaction? > >>> > >>> I had only the (new) transaction case in mind, but sure you could add > >>> a `transacted` boolean parameter. > >>> > >>> Or we make it explicit with a better method name: > >>> > >>> s.executeInSubtransaction( session -> session.save(...) ); > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> > > >>> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero < > sanne(a)hibernate.org&gt; > >>> > wrote: > >>> >> > >>> >> Today porting some benchmark code to Hibernate ORM 5.2 I had > several > >>> >> difficulties around the fact that the code now needs to be > different > >>> >> depending on transactions being container managed or not. > >>> >> > >>> >> My goal was to have a single benchmark test which I could compile > once > >>> >> and run in either JavaSE or CMT; with some help from Steve I > figured > >>> >> the necessary incantations out but ... it looks very unpractical. > >>> >> > >>> >> One way is to use an isolation delegate, which looks like this: > >>> >> > >>> >> final SessionImplementor session = (SessionImplementor) s; > >>> >> > >>> >> > >>> >> > session.getTransactionCoordinator().createIsolationDelegate().delegateWork( > >>> >> new WorkExecutorVisitable() { > >>> >> @ Override > >>> >> public Object accept(WorkExecutor executor, Connection > >>> >> connection) throws SQLException { > >>> >> /// Some work with PreparedStatement on Connection.. > >>> >> } > >>> >> }, true ); > >>> >> > >>> >> This worked fine for some raw SQL used for the benchmark > >>> >> initialization, but in another case I'd prefer to use the Session > API > >>> >> rather than dealing with PreparedStatements and native connections; > >>> >> it looks like we don't have an equivalent "run code in isolation" > for > >>> >> the Session ? > >>> >> > >>> >> It would be great if I could just pass a lambda to a Session and > have > >>> >> this executed on a "child Session" in the scope of a "child > >>> >> Transaction", or just start and commit a transaction if there isn't > >>> >> one. > >>> >> > >>> >> s.executeInIsolation( session -> session.save(...) ); > >>> >> > >>> >> So I'd expect that details like how to begin the transaction, how > it > >>> >> should be committed (or rolled back in case of exceptions), how to > >>> >> lookup a TransactionManager, and especially how to not leak > resources > >>> >> should be handled for the user. > >>> >> > >>> >> Obviously the inner Session instance is a different one than the > >>> >> outer, so any data returned by this block should be considered > >>> >> detached; maybe this limitation would be clearer if the method was > >>> >> hosted on SessionFactory or StatelessSession instead? > >>> >> Although it wouldn't necessarily have the limitations of a > >>> >> StalessSession, and it would be nice to have the inner transaction > >>> >> behave as a nested one when there's already one in the host > Session. > >>> >> > >>> >> Looking forward for comments and improvement ideas :) > >>> >> > >>> >> Thanks, > >>> >> Sanne > >>> >> _______________________________________________ > >>> >> hibernate-dev mailing list > >>> >> hibernate-dev(a)lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >