Hey
marc fleury wrote:
> Ok the MO is what we use in the containerInvoker to retrieve the objects.
>
> It is a replacement for the byte[] and ObjectInputStreamWithClassLoader that
> Rickard, I and RMH put one fine night back when... the problem then was
> that these puppies are very memory intensive and are used quite a lot and so
> we introduced pools of reusable thingies.
>
> My question is (rickard) does MarshalledObject serialize/deserialize
> 1- add one serialization (i.e. 2 steps to byte[] store, instead of one in
> the db)
Yes and "no". The object is first serialized to an internal byte[] in
the MO. When this object is stored in the DB the MO is serialized,
however serializing a byte[] doesn't really do anything (since the hard
work is already done).
It's the same thing as with the remote invocations (double
serialization, where the last step has very low overhead).
So, IMHO, that's a No, but it's a matter of opinion I guess.
> 2- do we know that they behave nicely or are we prettier with the reusable
> ones?
I asked Peter Jones on the RMI team about this (who wrote the MO code),
and have also talked to the JRockit JVM (the Swedish server JVM) guys
about this. Peter said that it wouldn't be a problem, and the JRockit
guy said something like "DO NOT CACHE *ANYTHING*! WAAAH! We can handle
that through garbage collection mgmt *MUCH* better than you can" Yes, he
was pretty upset about the general idea of Java code doing caching. He
didn't even understand why we wanted to use pools for the EJB's, because
it seems as though if the instantiation overhead is fairly small (i.e.
set*Context doesn't do much) you don't need a pool at all with newer
JVM's, since they are so good at memory management. That's the
impression I got anyway.
So, I guess the answer is: yes, they behave nicely. :-)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
