Sorry for the late follow up on this one.
Even after pruning JIRA of non-important issues targeted for 5.6 there
are still several ones open and I suspect it would take more than two
weeks. So while I would generally agree with Gunnar's suggestion to
try hard to not overlap work on active branches
Naming aside, my favorite approach is to have an "executor" available from
SessionFactory for accepting this functional-interface (lambda). The
executor would be configured with whether to isolate the work and whether
to transact it. Something like:
Executor getExecutor(boolean isolated, boolean
Most transaction systems do not support nested transactions
On Wed, Sep 14, 2016 at 3:13 PM Sanne Grinovero wrote:
> On 14 September 2016 at 21:02, Steve Ebersole wrote:
> > Also, why do you keep defining this in terms of Session, rather than
> > SessionFactory?
>
> I mentioned that same doubt
On 14 September 2016 at 21:02, Steve Ebersole 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 bet
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 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
"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 wrote:
> On 14 September 2016 at 20:32, Steve Ebersole wrote:
> > The problem with "execute in isolation" here is that the "isol
On 14 September 2016 at 20:32, Steve Ebersole 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 exampl
As another option we could define something like this on SF:
T doInIsolatedSession(BiFunction work);
T doInIsolatedSession(Function work);
The spec here would be to make sure any current transaction is suspended
(JTA), a new Session opened, the function performed and the suspended
transaction i
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
arg
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
That would be my personal opinion.
On Wed, Sep 14, 2016 at 11:24 AM Sanne Grinovero
wrote:
> On 14 September 2016 at 17:16, Steve Ebersole wrote:
> > To be clear, I mean "never end the transaction locally". It's like any
> > resource handling... if you start/begin/open something you should
>
On 14 September 2016 at 17:16, Steve Ebersole wrote:
> To be clear, I mean "never end the transaction locally". It's like any
> resource handling... if you start/begin/open something you should
> stop/end/close it. IMHO.
Thanks for the clarifications. I agree on the "who opens close"
principle.
To be clear, I mean "never end the transaction locally". It's like any
resource handling... if you start/begin/open something you should
stop/end/close it. IMHO.
On Wed, Sep 14, 2016 at 11:15 AM Steve Ebersole wrote:
> Yes, it was intentional. As you say it is totally reasonable.
>
> The pro
Yes, it was intentional. As you say it is totally reasonable.
The problem is "matching". Like it was no problem to call begin() before
but what happened if the txn was commited multiple times was wonky. In
fact JPA explicitly forbids it multiple calls to commit (as well as
multiple calls to beg
Hi Steve,
as a follow up of migrating #getTransaction() usage to
session.accessTransaction() I now noticed a difference:
we had previous code like this:
Transaction transaction = session.getTransaction();
transaction.begin();
Which worked fine even though the user is actually using an
EntityMana
15 matches
Mail list logo
