On 10/10/2012 02:26 AM, Emmanuel Bernard wrote: > Yes my proposal would imply we pass along the cache data structure through > all of our internal methods. > My concerns about byte code enhancement are a bit diffuse but relate to: > > - does it add an extra build step to users?
No, we'd go all out and complete both runtime and buildtime enhancement options. > - how much configuration is needed in SE? As far as I understand it, its just a matter of defining the agent as a VM start option. This is all new to me too, so not sure of all the specifics. > - has JBoss AS finally implemented the temporary class loaders required for > runtime byte code enhancement (JPA contract)? Well there is already code in place, that you put in place, that does the existing limited runtime enhancement we already support when building a container managed EMF. Not sure why you did that nor what containers do/don't support that. > - how does that all play when entities are serialized? > - can I unserialize entities on different a different VM? Regarding ser/deser... If you are asking about physically, then yes it should work as long as any fields we enhance into the entity are defined as transient. If you mean logically, then I think yes as well. Anytime an entity is serialized it would essentially become un-managed, which is exactly what happens today too. And just like today as well, reattachment would mean an implied dirtiness. Of course, we would be enhancing the entity to implement a particular contract. Users would have the option to manually implement that interface themselves and not even require bytecode enhancement at all. This *could* have some nice benefits like smarter reattachment (rather that implied dirtiness). Etc. > But more importantly I had the feeling that the cache approach would have > less intrusive than the byte code enhancement approach but your email made me > change my mind. Propagating the cache would be more intrusive assuming we > don't want thread local, and we probably don't want these. ThreadLocals are nice... when they work. But I have seen lots of cases were they maybe don't get cleared and all kinds of hard-to-debug problems start to appear when threads are pooled. It certainly takes a lot of defensiveness. > Would using a service that store cache data structures by session work? I am > thinking out loud here trying to push the cache idea before discarding it. > That would require a weak-key concurrent map. The one I know is the one Jason > wrote as a proposal for SE. I. Cannot remember where we use it but it must be > in Search or in Validator. Well I have been thinking about "identifying" sessions by assigning them a unique id (uuid?) when the session is started. That could help with the requirement for a specific type of map. That said, not really sure what this buys us. It still leaves open the same potential for leaks as using a ThreadLocal (though not as potentially disruptive). Have y'all seen any performance numbers that show the limits within which this "context cache" alternative is actually beneficial? Seems to me there will be a tipping point here beyond which it would actually make performance worse. -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
