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
- 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
- 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
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.