Caching Java Client Objects in 3 tier system

Post #107,586 by johnu 6/27/03 5:01:04 PM Reply	Caching Java Client Objects in 3 tier system I'm working on a 3 tier Java application with a GUI front end. The front end is fairly complex so I would like to have my domain objects available on the client as well as the server. So this is what the architecture looks like: UI -> Presenter -> Commands -> Domain objects -> Data Access Layer The commands are executed on the server in a command processor (which is implemented as a session bean) and the data access layer uses Hibernate. So here's the issue. The presenter sends a command to the server and get's back the results. The presenter now has a graph of objects. Later the presenter sends another command that returns a graph of objects, some of which are already in the previous graph of objects. Since they are deserialized, I know have duplicate objects on the client. This is bad. My bright idea is to create a Registry on the client that keeps track of client side objects. When an object's readResolve method is called, it can look in the registry and if it's already there, return the object from the registry instead. Are there any (hopefully open source non-GPL) products out there that already do this sort of thing? Thanks, John
Post #107,661 by tuberculosis 6/28/03 12:24:31 AM Reply	Re: Caching Java Client Objects in 3 tier system "My bright idea is to create a Registry on the client that keeps track of client side objects. When an object's readResolve method is called, it can look in the registry and if it's already there, return the object from the registry instead." This is an ancient pattern. Its used by nearly every system that does Object-DataStore mapping. I suppose the big question I would have is "why the 3rd tier"? Not logical tier - you need that - but physical tier. 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. At all times you need to maintain cached copies of the original fetched values to use for optimistic locking to maintain data integrity. So you have a class, unique ID (primary key attributes generally), the fetched values, and your working values. When you are going to resave the data back into the db, you use all the original values as part of your where clause, check the row count on your update, and if its not 1, toss an exception and roll the whole mess back and start over. You might take a look at [link\|http://www.solarmetric.com\|http://www.solarmetric.com] - they have a JDO package that looks pretty decent. It might help you out. Something free might be Cayenne at [link\|http://www.objectstyle.org/cayenne/userguide/design/\|http://www.objectsty...userguide/design/]. For this, you might need to make your middle layer look like a database to your client. "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
Post #107,850 by johnu 6/30/03 8:36:46 AM Reply	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
Post #107,908 by tuberculosis 6/30/03 2:54:05 PM Reply	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
Post #107,919 by johnu 6/30/03 4:06:30 PM Reply	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

Welcome to IWETHEY!