Re: Serialization, RMI and deep copy
From: EJP (nobody_at_nowhere.net)
Date: 10/31/03
- Next message: MasterChief: "dummy proof"
- Previous message: EJP: "Re: Serialization and Versioning of Classes"
- In reply to: JP: "Serialization, RMI and deep copy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 04:48:29 GMT
Yes, you should clone the object before returning it, so that the
lockout time is as short as possible. You might even look into making a
clone available every time the data changes, and set a flag when
updating rather than requiring a computation, so you only need to lock
when updating.
However you don't have to *explicitly* serialize anything at all, RMI
does this for you. Just return the root object. You are
serializing/deserializing twice. Also all the affected classes should
have serialveruids declared, to save a lot of runtime computation.
EJP
JP wrote:
>
> All,
>
> I need help with the following problem that stretches the limit of my
> limited Java experience.
>
> Situation:
> In a centralized management application, I have a in-memory store
> (singleton) that contains configuration information. Multiple clients can
> request, through RMI, a configuration update (difference of what they have
> vs what the store now contains). These updates can be very large and the
> client requests can happen at any time (asynchronous). A web browser is also
> a client of the store and can insert configuration changes.
>
> Problem:
> It takes a non-negligible amount of time to serve a configuration update
> request from a client. First, the store must calculate what information is
> pertinent, then that update object must be serialized through RMI. While
> that is happening, the store must be locked to maintain data consistency.
> The consequence is the browser responsiveness goes down the tube, especially
> if we're dealing with poor network conditions that make serialization
> slow/fail.
>
> Proposed solution:
> To minimize the store locking period, I propose to make a copy of the
> configuration update object right after the calculation, release the store
> lock and return the copy through RMI. Since the update object can be quite
> complex, I thought of using serialization for the deep-copy operation. If I
> can serialize to a data structure of some kind (ByteArrayOutputStream?), I
> could return that object through RMI and the clients could de-serialize
> their updates.
>
> Facts:
> The configuration object can be serialized. We have plenty of memory for the
> copy operation. The design must withstand network failure conditions.
>
> Questions:
> - How do I do this? I'm pretty sure I could write the updates to a
> ByteArrayOutputStream, but the client will need an InputStream of some sort
> to read the object.
>
> - Is it more efficient to "RMI" a byte array than a complex object if they
> are of the same size? Since I want to serialize my update object prior to
> the RMI call returning (for deep-copy purpose), I was hoping there was a way
> to make the RMI serialization more efficient. Otherwise, it sounds like
> duplicated work.
>
> Thanks in advance for any help you can provide,
> JP
- Next message: MasterChief: "dummy proof"
- Previous message: EJP: "Re: Serialization and Versioning of Classes"
- In reply to: JP: "Serialization, RMI and deep copy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
