On 25 October 2017 at 17:13, Jonathan Halliday
wrote:
>
> so you have some form of implicit cleanup that de-registers Synchronizations
> when the transaction finishes, or do they stay registered and re-fire for
> each tx on the connection?
>
> As to the multiple registration semantics, IIRC the ar
On 25 October 2017 at 16:22, Steve Ebersole wrote:
>
>> Yes that would work for me, but thinking about the implementation it
>> implies you'd need to hold on to both a Set and a Map, and then we'd
>> be exposed to silly usage like people adding the same synchronization
>> twice in two different wa
so you have some form of implicit cleanup that de-registers
Synchronizations when the transaction finishes, or do they stay
registered and re-fire for each tx on the connection?
As to the multiple registration semantics, IIRC the arjuna code allows
the same Synchronization to be registered mul
The SynchronizationRegistry is kept per-LogicalConncection which might span
multiple physical transactions.
On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday <
jonathan.halli...@redhat.com> wrote:
>
> right, a lot of JTA works on the 'tx bound to thread' approach and it's
> a right pain in async
right, a lot of JTA works on the 'tx bound to thread' approach and it's
a right pain in async I/O thread pooled environments like vert.x That's
one of the reasons why sticking a get/put api on the Transaction
instance abstraction instead may make more sense, though I'm guessing
your Synchroni
Also, unless I am mistaken `TransactionSynchronizationRegistry#put` works
on the principle that the "current transaction" is associated with the
current thread. I absolutely want to stay away from that as an assumption
here. It simply does not hold true in the JDBC txn case.
On Wed, Oct 25, 2017
Jonathan, we aren't going to be exposing this or using this
via TransactionSynchronizationRegistry. Your comment about a "dummy" in
the JDBC txn case is exactly why. We already have such an abstraction :
SynchronizationRegistry
On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole wrote:
> Yes that
sure, though I was thinking in terms of storing the stateful sync
directly into the registry, not separating out the state first. Your api
proposal made that storage a side effect of the registration call, but
with the javax.transaction api it's an additional call, roughly
tsr.registerSync(sta
> Yes that would work for me, but thinking about the implementation it
> implies you'd need to hold on to both a Set and a Map, and then we'd
> be exposed to silly usage like people adding the same synchronization
> twice in two different ways?
>
Does it? Nothing in the SPI requires us to store t
On 25 October 2017 at 16:05, Steve Ebersole wrote:
> Yes, but that is only available in JTA environments. Ours is available no
> matter what kind of transaction environment we are executing in.
>
> Sanne, how about instead a separate registration method accepting a
> "registration key"? E.g.:
>
Yes, but that is only available in JTA environments. Ours is available no
matter what kind of transaction environment we are executing in.
Sanne, how about instead a separate registration method accepting a
"registration key"? E.g.:
public interface SynchronizationRegistry extends Serializable
Hi Jonathan!
So I have multiple options, but fundamentally I have an ORM
SynchronizationRegistry today. We could either follow the example of
the javax.transaction API in evolving the ORM SPI, or apparently I
could explore making our Synchronization stateless and store the state
in this other map
I had the same issue in 2LC and we ended up passing
CacheTransactionContext to all SPI calls (for ORM6). In case of
Infinispan impl this will be a stateful object, probably implementing
the Synchronization iface as well (to reduce object count), and 2LC will
store all the beforeCompletion/after
The javax.transaction version of that interface already functions as a
per-transaction hashmap, with put/get operations available. If you can
use it directly, then just pick a suitable lookup key - FQCN or even the
sync impl .class itself, since the key is Object type. If not then at
least ret
Hi,
We just released Hibernate Validator 6.0.4.Final.
The main point of this release is to provide a patch file for WildFly
11 Final but we also included some nice performance improvements and
bugfixes.
It is a recommended upgrade for everyone already using 6.0.x.
For more information, read the
Hi Steve,
do you think it would be sensible for me to explore introducing some
kind of synchronization lookup method on
org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
Today it only exposes a `registerSynchronization` method, which we use
extensively, but then we also have quite
16 matches
Mail list logo
