Repost: RMI Conundrum

[VisionSet]

I send an object over RMI

// can't modify myObject here, I don't want server to see modifications.
myRemoteMethod(myObject);
// too late to modify myObject here, I don't want to wait for transmission
delay

But I want to do something to myObject after it has been safely serialised
(ie I don't want the server to know of the change I want to make). I don't
want to have to wait until the remote method returns. If I fire the method
off in its own thread then I can ascertain when that thread is running, but
I can't be sure when myObject has been serialised.
I realise I can get round this by cloning myObject but is there an
alternative. Seems a pain to have to implement cloning throughout my object
tree just for this, especially when serialisation is going to do it for me -
just that I can't get at it - or can I?

I think I can use Serialisation itself as a lower performance alternative to
cloning.
I'll probably do that if there is no alternative.

TIA

 

[John C. Bollinger]

I send an object over RMI

// can't modify myObject here, I don't want server to see modifications.
myRemoteMethod(myObject);
// too late to modify myObject here, I don't want to wait for transmission
delay

But I want to do something to myObject after it has been safely serialised
(ie I don't want the server to know of the change I want to make). I don't
want to have to wait until the remote method returns. If I fire the method
off in its own thread then I can ascertain when that thread is running, but
I can't be sure when myObject has been serialised.
I realise I can get round this by cloning myObject but is there an
alternative. Seems a pain to have to implement cloning throughout my object
tree just for this, especially when serialisation is going to do it for me -
just that I can't get at it - or can I?

If you want the client and server to see a different views of the
transmitted (non-remotable) object, then you have a few choices. You
could implement the readObject() and/or writeObject() methods to take
control of the serialization behavior. Alternatively, you could
implement Externalizable and take complete responsibility for the
serialization and deserialization.

Depending on the details of what you want to accomplish, however, you
might also want to consider using a thin wrapper that provides the
desired view to the client:

myRemoteMethod(new ModifiedView(myObject));

 

[puzzlecracker]

If you want the client and server to see a different views of the
transmitted (non-remotable) object, then you have a few choices. You
could implement the readObject() and/or writeObject() methods to take
control of the serialization behavior. Alternatively, you could
implement Externalizable and take complete responsibility for the
serialization and deserialization.

Depending on the details of what you want to accomplish, however, you
might also want to consider using a thin wrapper that provides the
desired view to the client:

myRemoteMethod(new ModifiedView(myObject));

John, are related to the current President of Columbia University?

 

[E.J. Pitt]

I guess the real question is, given that you want to do something in
between the marshalling of your RMI call and the unmarshalling of its
result, why you are using RMI at all? What you want can be accomplished
naturally by out.writeObject(myObject); doSomethingLocalWith(myObject);
result = in.readObject();

 

[John C. Bollinger]

John C. Bollinger wrote:
[...]



John, are related to the current President of Columbia University?

Not to my knowledge. The family has been in the U. S. of A. since
before it was either U. or S., however, and it has branches (and variant
spellings) everywhere. My particular branch is from the St. Louis and
southeast Missouri region (since the 1830's), whereas President
Bollinger of Columbia U. is from California.