[hibernate-dev] Bytecode enhancement

[Steve Ebersole]

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.

-- 
steve at hibernate.org
http://hibernate.org