OK,
FastCache was the first iteration of solving the problem. The new iteration
CacheKey is more generic and allows the container caches to specify what
kind of internal key you use. It is *completely* transparent to the
container.
One thing that I believe you might have missed is the fact that the only
place that the changes were finally done and visible were of course (as you
saw) the cache, but also the client. In fact the client now holds a
"cachekey" in the case of entities (and the implementation I propose of it
is the fastKey). Again 2 places, client and cache, the rest of the
container DOES NOT see it.
Now, I read your "proposal" of the "using reflection to look at the key" as
a way to extract the values of the fields and build a consistent hashing
algorythm based on these. Jonathan Weedon, from Inprise, was posting on
ejb-interest the other day talking about exactly the same problem. In short
he describes (in one line ;-) that "he doesn't trust developers to implement
hash and equals correctly" and goes on to lament the fact that these
*seriously* break the container cache implementations (as we saw) for most
container implementations out there. His solution, simpler than yours (but
you haven't really detailed yours) is to serialize a PK to a series of byte
and hash on these (byte[] hash is consistent) I find this solution kind of
elegant (and probably faster than yours). Speed is going to be an issue on
cache and introspection and/or serialization are heavy operations to perform
at *each* invocation.
HOWEVER, my understanding of the problem is that it is not a "philosophical"
question, and not even a "spec compliance" question. In fact the I will
argue that there are no incompatibilities. Here goes.
Right now the cache does 3 things
1- key->wrapper lookup
2- wrapper concurrency Tx management
3- LRU/ passivation algo on wrapper->instances (not done yet, that's what
you are working on afaik)
As we know (and allude to the problem) #2 is kind of messy right now and we
discussed with Rickard on a refactoring (I think it's a FIXME). What I
argue is that the "incompatibility" your implementation sees is on 1-3
meaning that since these are mixed you can rely on either implementation in
CVS. I believe we should factor the 3 and so LRU must work on wrappers (1-1
with instances) but that the cache key management is an orthogonal issue.
That is fairly easy to implement but I would need to see how you keep track
of usage. In jboss1.0 we had a "pool" (really a cache) that was aware of
updatedWrappers and could decide accordingly. There is much power in
allowing separate N-1 mapping of the KEYS (#1) since the implementation that
is in CacheKey (interface) / FastKey (implementation) does not involve
introspection and/or serialization as in the solution of Jonathan.
in clear, once a client is hooked up he has a cachekey that is an entrance
to the cache (no calculation in our case) and the right solution to
alternate lookups (say a findByYadaYada) is the jonathan solution (imho).
THEN the lookups are done by a "cache dispatcher", THEN the WrapperManager
(leaves in cache or outside, design (non-important;-)) can deal with
2 (access) 3 (algo) independently.
I will repeat that it is not even a "spec issue", it is a design issue but
one that is limited to the cache.
Bottom line: send me the code and we will try to factor it right, at least
we can work on an implementation that does 1-2-3 clearly.
marc
_____________________
"Do-Re-Mi as easy as
1-2-3"
-- Michael Jackson--
_____________________
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
> Sent: Monday, September 11, 2000 2:53 PM
> To: jBoss Development Mailing List (E-mail)
> Subject: [jBoss-Dev] The new caches for entity and stateful beans
>
>
> 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
>
>
>
