Hi Jonathan,
Actually yesturday I thought up of a trivial modification to FatKey that may
make it compatible with Inprise, as well as any other container that hashes
primary keys using serialization: Make FatKey's reference to the data
container 'transient'!
In my original post, I said both my bean class and my primary key classes
extend BeanDataContainer, which is
class BeanDataContainer
{
private Map mData;
public Object getField(String aKey);
public void putField(String aKey, Object aDatum);
}
Well, I wouldn't want to make the reference to the mData Map transient
because my bean instances will be no good if container decides to
passivate/activate them. Hence I can simply create a
TransientBeanDataContainer class:
class TransientBeanDataContainer
{
private transient Map mData;
...
}
And have my FatKey extend this. Voila! If Inprise tries to calculate the
PK digest via serialization, it will only see non-transient fields, which
are the actual values germaine to the primary key. And this may also solve
the problem you described below about PKs being serialized into Handles.
I agree with you: My FatKey pattern here is not for the faint of heart!
It's for developers who understand the limitations of current container
implementations and want to do some custom-tailoring. I do not trust CMP
management of this generation of containers; perhaps EJB 2.0 and the next
generation of containers will win back my trust... Until then I merely
offer interested developers this BMP-caching alternative.
Gene
-----Original Message-----
From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 07, 2000 9:41 AM
To: Gene Chuang
Subject: Re: FatKey Pattern... was: Does it ever make sense to
putamulti-bean-retur ningfindmethodin an entity bean?
Gene Chuang wrote:
> Finally, you do drive a good point with your final observation: a FatKey
> can slip out of a transaction from which it was created without ejbLoad
> being called on it (client can call EJBObject.getPrimaryKey() and
serialize
> it for later use, but NOT call any business methods that will result in a
> ejbLoad), and this "dirty" FatKey can slip into a subsequent transaction.
> But they way I see it, and correct me if I'm wrong, the only way a Primary
> key can be "reused" in a subsequent transaction is through
findByPrimaryKey,
> right? So here's how I get around the stale key problem: In my
> findByPrimaryKey implementation (as opposed to my findByXXXX
> implementation), even though I get a FatKey passed in from the method
> argument, I recreate the FatKey again regardless of what's in the argument
> FatKey and return that to the container! Hence I guess the only really
> annoyance with a FatKey across transactions is that FatKey is, well, fat
> (and takes up memory)! But in my architecture I aways invoke business
> methods from the collection of EJBObjects I get from a findByXXX, AND I
> never really store a Primary Key for outside the transaction usage (I
would
> store the Handle instead), so I managed to avoid this possible "loophole".
Gene,
Here, you are wrong. I can't speak for all vendors, but it will be common
that the primary key is serialized into the object reference. Furthermore,
it is also likely that a primary key is serialized into the Handle. Thus,
any way that you hold onto a reference to a FatKey-enabled entity bean is
invalid, be it via primary key, object reference, or handle. Sorry, but
FatKeys really are broken in a number of ways.
Again, I am not saying that your application is broken. It is likely that
you have avoided all the failure cases of using FatKeys. But I would
strongly
recommend caution in using this technique, as it makes very strong
assumptions
about how an EJB container is implemented, and is thus inherently
non-portable
and usage-specific.
-jkw
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
