I guess the proposed solutions are more suitable for one-to-one checking rather than broadcasting the change  to other online clients. (read AJAX documentation)

some drawbacks:

1) based on blueprint examples, refreshing data  mechanism could be helpful. AJAX interactions support polling. to some extent this could answer your question, but highly depends on the data rate.

2) to my knowledge it is mainly used for web  based applications (still could be suitable for you)

3) not all browsers  support it

By having a look at the question, JMS could be one way of broadcasting the updates? but how often do you want to send JMS messages and how do you guarantee that the latest message contains the latest update (if you have standalone message subscribers)?

manually listening/polling for changes could be another solution? but how do you know what is the best interval as the value might change again right after you have received the latest update in your last interval. In high rate of data manipulating systems, i.e. stock options as data is changing in a matter of seconds, these solutions are not going to work.

The question means that you want to protect the shared resource from multiple client  access. You need to serialize the access to the resource. But this is done automatically for you if you support transactions (by performing intelligent locks).

I assume that each of your clients have their operations (data manipulations) performed in a transaction (transaction could live on the server). I guess here you should administer the transaction isolation levels (read committed, read  uncommitted, repeatable reads and serializable). I advise you to read through the isolations levels to control the lock/unlock of the values on the server/DB as the improper use of such transaction attributes will have major drawbacks on your overall performance. (the last bit is very important)

As an example, client "A" might change x from 2 to 3 while the rest of the clients still see the value as 2. According to AJAX validations, when client B wants to write value 2 back to the server, it might NOT get rejected as 2 might still seem as to be valid value and the server  may take it as a new change (after client "A" has set it to 3). How does your server can determine which one is correct? for this you need extra checking per attribute on the server which is surely not a good option.

I guess the answer to your question relies on how you define the transaction attributes and isolation levels and how you resolve "dirty reads", "unrepeatable reads" or "phantom reads". transaction will control the access to the resource and upon update by others, the new client will either be blocked or rejected. this is done automatically for you and all you need to do is to set up proper isolation level.

Note that above is based on EJB 2.1 and J2EE 1.4 and the drawback is that this solution works only for BMT and if implemented in CMT is would not be portable (container and DB wise)