> Hmm, that does seem strange that you can serialize the home & pk, but not
> the handle.
Yes, it does seem strange which is why I am assuming there is something more
fundamental that I just don't yet get.
> I'm afraid I have never used EJB handles, so I won't be much
> help there. Every time I have though that I should use a handle, it has
> turned out that an EJB reference (a javax.ejb.EJBObject, actually) would
> work just as well. An EJBObject should be valid across bean passivations,
> but I don't know if it's guaranteed valid across server restarts.
I don't know about server restarts either. As an experiment I let my session
bean be passivated with a reference to an EB, and it did activate properly.
However, this is not what we are supposed to do if we need to pass a
reference out to a remote (beyond of app server) client. That is why I was
using handles. My thinking is that the wrapper class (which holds the EB
reference) shouldn't have to care if it was being used by another EJB in the
same app server or being sent far, far, away. It should do the same thing no
matter what. (I hope I can figure out how to achieve this in practice).
> I still don't quite understand where readObject() and writeObject() are
> being used. Did you implement these methods in your session bean, to
> manually serialize your utility class? Or did you implement them in your
> utility class, to manually serialize the handles? I guess I'm not quite
> sure what the manual serialization is for.
I implemented it in the wrapper classes for the EBs. I understood (and
still believe) that I should pass EB handles to remote clients, and not the
reference to EJBObject. Passing the remote interface is useless because it
does not identify a specific EB ie. one associated with its primary key. My
client via its SFSB asks for acess to an EB, but it is the SFSB that figures
out which EB the client should access based on its state. So the SFSB must
pass back a specific reference, not just an interface.
Its the wrapper around this EB reference that uses readObject() and
writeObject(). The wrapper instance holds a reference to a specific EB but
can't let itself be serialized with this reference - because it does not know
where it will be deserialized it must swap the reference to the EB with its
handle and let the handle be serialized instead - ala writeObject(). Upon
deserialization it uses readObject to get the handle and then convert it back
to a proper EB reference wake-up.
Here an example from one of my wrappers (about 12 lines):
private transient CachedRecordSet crs;
-- other non transient fields omitted --
-- business logic omitted --
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
{
out.defaultWriteObject();
Handle handle = bean.getHandle();
out.writeObject(handle);
}
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException
{
in.defaultReadObject();
Handle handle = (Handle) in.readObject();
bean = (CachedRecordSet)
javax.rmi.PortableRemoteObject.narrow(handle.getEJBObject(),
CachedRecordSet.class);
}
> If your utility object has a reference to entity bean (E), and (E) is
> passivated, the utility's next call to (E) will reactivate it.
Yes.
> If that utility object is a non-transient data member of a session bean
> (S), and (S) is passivated, the utility object should be serialized
> (assuming it's serailziable.).
Yes.
> When (S) is reactivated, the utility's reference to (E) should be intact.
Yes. But, by testing, only if the utility's reference was serialized NOT
using a handle (ie do nothing, or use the home/pk substitution).
> If the utility object is passed out to a client (an EJB client or a
> servlet,) I think that your only problem could be the client surviving
> server restarts... your reference to (E) would go away unless you
> kept a handle instead of an EJBObject.
Yes. When passing to a remote client I can use handles, but when using it
with a local client, as with a SFSB in same application, I seem to have to
make sure that if the SFSB gets passivated that it does NOT use handles.
So when being serialized it seems that the bean referene needs to know why
its being serialized so that it can choose the correct serialized format !!
And IMHO that sucks.
> I hope that helps
Yes. Although I don't think the problem is solved, in the short run I can
make it work, and that puts me far ahead of where I was a few days ago.
>, but I'm still not quite sure if I'm addressing the right
> question
You are.
> (or if I'm telling you things you already know.)
Well, I'm not quite sure what exactly I do know... so no.
Thanks.
Mike
===================
Mike Finn
Tactical Executive Systems
[EMAIL PROTECTED]
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
