AltRMI serialization issue & request for help

[Paul Hammant <Pa...@yahoo.com>]

Folks,

[ Cross posted from commons-dev ]

For the following class ...

 Person {
   private String name;
   public void setName(String name) { this.name = name; }
   public String getName() { return name; }
 }

... If it is sent over an ObjectStream to a client from a server, then 
has it's name changed on the server with setName() and sent again, the 
client cannot see the name change.  The reason is that the ObjectStream 
makes an 'optimization' and decides that the person object does not need 
to be deserialized a second time because it already has it.  The issue 
is fixed by hitting reset() after each write of Object, but this halves 
performance, probably I guess because the reset() has to be communicated 
to the client at that time.  A resetDelay() might be nice.

To solve the issue I'm going to have to write a cut-down equivalent to 
ObjectStream that makes no such optimzations.  It would be implemented 
as yet another transport (the transports themselves are as invisible as 
possible to the user).

If anyone has time and interest, it would be nice to get some help for 
this.

I'm also looking to make adaptors for AltRMI so that it can be used in 
JNDI.  For those that are interesed -> 
http://java.sun.com/products/jndi/tutorial/objects/storing/remote.html 
is a good starting point.

Regards,

- Paul H



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: AltRMI serialization issue & request for help

[Paul Hammant <Pa...@yahoo.com>]

Peter

>[ re Objstream bug ] 
>I would highly recomend that you call reset() after each invocation of a 
>method - it causes a lot of pain otherwise and I have been burnt by it before 
>;)
>
Am going to make it a configuration choice.  For an API that only has 
methods that only use primatives & java.lang wrappers for same as return 
classes and args, it works fine as is.

>>I'm also looking to make adaptors for AltRMI so that it can be used in
>>JNDI.  For those that are interesed ->
>>http://java.sun.com/products/jndi/tutorial/objects/storing/remote.html
>>is a good starting point.
>>
>
>kool - so do you mean you are going to create and object factory + a way to 
>create Reference objects or something?
>
Yes.  I am not sure but there is a possibility to masquerade the AltRMI 
hosted interfaces as plain beans rather than the RMI types.

I don't like JNDI though.  Like SAX it kinda thunks itself into the VM.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: AltRMI serialization issue & request for help

[Peter Donald <pe...@apache.org>]

Hi,

On Wed, 16 Jan 2002 23:01, Paul Hammant wrote:
> ... If it is sent over an ObjectStream to a client from a server, then
> has it's name changed on the server with setName() and sent again, the
> client cannot see the name change.  The reason is that the ObjectStream
> makes an 'optimization' and decides that the person object does not need
> to be deserialized a second time because it already has it.  The issue
> is fixed by hitting reset() after each write of Object, but this halves
> performance, probably I guess because the reset() has to be communicated
> to the client at that time.  A resetDelay() might be nice.

I would highly recomend that you call reset() after each invocation of a 
method - it causes a lot of pain otherwise and I have been burnt by it before 
;)

> I'm also looking to make adaptors for AltRMI so that it can be used in
> JNDI.  For those that are interesed ->
> http://java.sun.com/products/jndi/tutorial/objects/storing/remote.html
> is a good starting point.

kool - so do you mean you are going to create and object factory + wa way to 
create Reference objects or something?

-- 
Cheers,

Pete

------------------------------------------
I just hate 'yes' men, don't you Smithers?
------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>