Hi Scott, In the particular case of the hibernate bytecode enhancer, it adds the org.hibernate.engine.spi.Managed marker interface to the entity so that it only performs the enhancement once. (that implies that you can't have the same entity enhanced for different features in the same class loader) Also, in theory, you could have multiple transformations applied to the same entity / PU. So what is it you really want to check ?!

I don't get you last paragraph ... why ORM will be only capable of registering one transformer,

and why will you need synchronization ?!

My reading on that javadoc is that you only get the transformation once (the first time that a class is loaded) and after that, if it's used by other PUs, it may not get the transformations those PUs specify.

I would like to add that the enhancer is synchronous (it only enhance one class at a time), hence my question about synchronization, but you were obviously looking at a different level. Regards, Luis Barreiro Middleware Performance Team <https://red.ht/sig> On 06/05/2018 07:08 PM, Scott Marlow wrote: Thanks, I think they probably intended that the persistence provider would use a marker interface like org.hibernate.engine.spi.Managed to ensure that the enhancement is only done once. Responses to your questions are inline below. On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro <lbarreiro(a)redhat.com&gt; wrote: > Hi Scott, > > In the particular case of the hibernate bytecode enhancer, it adds the > org.hibernate.engine.spi.Managed marker interface to the entity so that > it only performs the enhancement once. (that implies that you can't have > the same entity enhanced for different features in the same class loader) > > Also, in theory, you could have multiple transformations applied to the > same entity / PU. So what is it you really want to check ?! > Mostly, I'm trying to understand why the [1] javadoc requires that classes are only transformed only once, as I would expect that some persistence providers could want to register multiple transformers. > I don't get you last paragraph ... why ORM will be only capable of > registering one transformer, > If we update the WildFly JPA container JPADelegatingClassFileTransformer [2] to only allow the application entity class to be enhanced at most once (at runtime), ORM would be able to register multiple transformers but the first ORM transformer that actually enhances the entity class (e.g. transformer returns non-null return value), would need to terminate the "for each transformer" loop in [2]. Since, as you said, ORM is already using a marker interface to know when a class is already enhanced, it sounds like WildFly doesn't really need to enforce the [1] contract (with regard to only transforming the entity class once). > and why will you need synchronization ?! > If WildFly JPADelegatingClassFileTransformer [2] where modified to prevent more than one transformation of an entity class, that would include checking across (parallel) persistence unit deployment threads, which could be done with a Java synchronization lock. Scott [1] https://docs.oracle.com/javaee/7/api/javax/persistence/spi/ PersistenceUnitInfo.html#addTransformer-javax.persistence.spi. ClassTransformer- [2] https://github.com/wildfly/wildfly/blob/master/ jpa/subsystem/src/main/java/org/jboss/as/jpa/classloader/ JPADelegatingClassFileTransformer.java#L44

On 5 June 2018 at 14:43, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > The PersistenceUnitInfo#addTransformer javadoc [1] mentions: > > " > Add a transformer supplied by the provider that will be called for every > new class definition or class redefinition that gets loaded by the loader > returned by the getClassLoader() > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/ PersistenceUnitInfo.html#getClassLoader--> > method. The transformer has no effect on the result returned by the > getNewTempClassLoader() > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/ PersistenceUnitInfo.html#getNewTempClassLoader--> > method. Classes are only transformed once within the same classloading > scope, regardless of how many persistence units they may be a part of. > " > > Should we have a check somewhere that prevents the same entity class from > being enhanced multiple times? Should the check be in the JPA container or > in the persistence provider? Thought I would check here in case anyone > remembers the background of where the check was intended to be exactly. I suspect it's necessary to do this check in the container.

If you do it in the persistence provider, how can you guarantee that another persistence provider is not keeping track independently? > I assume that WildFly might be the best place to have the check but wanted > to ask here first, because if the JPA container does the checking, that > will mean that ORM will only be able to register one class transformer per > persistence unit. WildFly will also have to prevent other persistence > units from transforming the same entity class in a different thread (e.g. > since we typically deploy all of the persistence units in parallel, we will > need some synchronization). +1 > > Scott > > [1] > https://docs.oracle.com/javaee/7/api/javax/persistence/spi/ PersistenceUnitInfo.html#addTransformer-javax.persistence.spi. ClassTransformer- > > [2] https://github.com/wildfly/wildfly/pull/11297 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev