Hello all,
I'd like to discuss with you more in deep the caches. Since stateful is OK
(apart a minor problem related to concurrent calls between business methods
and EJBObject methods), for now on I will use cache meaning the cache for
entity beans.
The main problem of this cache is that, differently from stateful beans
where the id that identifies a bean is generated by jBoss, the id (or
Primary Key, PK) of the bean is not generated by jBoss, so it *must*
override hashCode and equals in a meaningful way (we'll see why).
No problem if the PK is a primitive type (or wrapper) or String, but for
complex PK not overriding hashCode and equals can generate the following
problem: when the PK object is serialized and deserialized in the
invocation, a new object of that class is created. If the PK class has the
hashCode and equals implementation inherited from java.lang.Object, in every
invocation the hashCode is different, since every time we create a new
object serializing and deserializing it.
So, first call will be a create call: this will put in the cache (which is
in the end a HashMap) the pair (PK, bean); the HashMap takes the PK's
hashCode (let's say 108567) as key and the bean as value; second call will
be a find call with the same PK object; when it arrives in the server we
deserialize it and we will have a different object representing the same PK;
its hashCode will be different (let's say 8754390) and we will have a cache
miss. This leads to have very soon the cache full of object, will burden the
server and make invocations slow (and maybe other things).
Marc solved this problem with the FastKey / FastCache.
Unfortunately, this is incompatible with the new cache implementation.
There is now a philosofic discussion if we should protect jBoss from
ignorance of the bean developer (that doesn't provide hashCode and equals to
his PK classes, or provides them wrongly) or if we should better go on along
with the specs. Note that this is an issue only when commit option is A and
when the hashCode and equals are not overridden.
I ended up with 2 implementation: the first is "plain specs" (I strongly
assume that hashCode and equals are well written); the second follows the
FastKey idea to give anyway the PK object an "id" and it is implemented as a
subclass of the new EntityInstanceCache (that has the same name of an
already existing interface but it is not related to).
The second option has no impact on other part of jBoss, differently from the
FastKey thing (for this reason the new cache implementation, if commited,
will remove the whole FastKey machinery). The real PK object slips through
the interceptor chain until it reaches the cache; only there it is wrapped
by another object that gives it hashCode and equals using reflection.
I think we can propose this as a *feature* of jBoss: you're a young bean
developer, don't know how to override hashCode ? Use our Safe Cache for your
beans. You're and experienced bean developer ? OK, use our normal cache,
you'll get a little more speed.
BTW, the new cache solves also the reentrant / concurrent problem for entity
beans, serializes the concurrent legal calls (ie will execute them one after
the other); I also have fixed the commit option (that is broken now), and it
passes the TestBeanClient test.
Marc, your thoughts about the FastCache and the solution I propose ?
Best regards,
Simon
