IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: Caching Java Client Objects in 3 tier system
I suppose the big question I would have is "why the 3rd tier"? Not logical tier - you need that - but physical tier.

Management would like to offer the software in an ASP model in the future. The next question would be "Why not an HTML interface?". Because management also mandates the user interface be as identical to the old PowerBuilder client/server UI as possible.

My suggestion to you is to not cache the domain objects in the server - move them to the client as an assembly - monkey with them - give them back to the server - execute server side processing on them, put them back in the db.

Yup. That's what we're doing now. I use Hibernate O/R library to handle data access and keep my server side processing stateless. The reason I need caching on the client is because I often make more than one call to the server during a user interaction and sometimes an object that's already on the client get's sent to the client in subsequent server calls.

Here's an example:

1) John Doe logs in. The system contacts the server to get the login information for a User. It returns the User object for John Doe.

2) The user opens his list of messages. The system contacts the server to get the list of messages. Each Message has a Sender and Addressee which are both Users. The server returns Messages for John Doe and he is the Addressee on them.

Because I'm using Hibernate on the server, it makes sure that the same instance of John Doe is associated with each message. Once it gets to the client and is deserialized, I have two instances of John Doe, the one associated with the messages and the one retrieved when the user logged in.

I need something on the client to make sure only one instance of User exists on the client side after multiple calls to the server.

Regards,
John
New Using Java Serialization?
If so, I'd consider subclassing ObjectOutputStream on the client and overriding readObject to call super to read the object, look it up in your cache, then return the cached object if found - otherwise entering this one into the cache and returning that.

That should solve your problem.



"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
New Re: Using Java Serialization?
If so, I'd consider subclassing ObjectOutputStream on the client and overriding readObject to call super to read the object, look it up in your cache, then return the cached object if found - otherwise entering this one into the cache and returning that.

Yup, except I'm implementing the readResolve method. This allows me to replace the object that's being deserialized during deserialization. I've got a simple "Registry" that uses HashMaps to cache data. I was hoping there were some more robust options already out there. If not, what I've got should work.

Thanks,
John
     Caching Java Client Objects in 3 tier system - (johnu) - (4)
         Re: Caching Java Client Objects in 3 tier system - (tuberculosis) - (3)
             Re: Caching Java Client Objects in 3 tier system - (johnu) - (2)
                 Using Java Serialization? - (tuberculosis) - (1)
                     Re: Using Java Serialization? - (johnu)

EGM: Who's that chick Mario is rescuing up there?
Brian: It's Princess Peach.
Kirk: It's a hooker.
Niko: She looks cut in half.
Tim: Oh wow... she's one of those pole dancers.
130 ms