update clients

[ionel]

Hi,

Let's say two clients access an EJB.
They both retrieve the same fields.

One changes the contents of a field.

How to tell the other client that the content has changed ?
Is it possible for the container to know who accessed a bean ?

I thought of using JMS in the Load() or Store() methods, publishing to a topic named like the Bean with, in the header, the name of the changed field.


Does anybody experienced the same need and find a suitable solution ?

If not, please feel free to criticize this solution or to post comments.

Thanks,
ionel

[dward2]

As cool as JMS notification on entity change sounds, with even a medium-sized system and a handful of users the network would be chuck-full of messages flyin' around.

I don't have a good quick suggestion for you to automatically get changes made from another client, but as far as making sure you don't overwrite others' changes, try this:

Implement either a LAST_MODIFIED timestamp column or VERSION number column on their entity so that if you want to do an update, your slsb interface to your entity will first make sure your lastmod or version matches up, otherwise an exception is thrown indicating that someone else changed the entity since you last pulled data from it. The exception could also hold a value object with the newer data.

I'm fairly certain you can find some design pattern examples at theserverside.com for this.

Hope this helps,
David

[jmschust]

This is not a bad solution just as long as the data doesn't change much. I'm using something similar for some somewhat-constant data. (changes about once per day, and I've put all my data within one entity bean instead of using the standard way of one bean per row). However, just like dward2 said, this puts lot's of overhead on the system.

The only other solution would to make your clients into servers also, and keep a reference to them. This in essance does exactly what JMS does, but with some limitation in overhead, if you have only a few clients. I would suggest however having one JMS client, internal to the server, 'notify' your other clients however, instead of just putting all the code into the ejbLoad and ejbStore.