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? On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sa...@hibernate.org> 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev