I have a simple set of model classes that are used on a client as part of
MVC and on a server for distributed access.  When a client updates a model
object, this object is sent to the server, many clients maybe interested in
this change and want to have updated versions themselves.
As I see it I have two basic options with the RMI approach I will be taking.

1/ Stubs/Skeletons are compiled for both directions such that when the
server receives an update it should then transmit an event to all interested
clients,  details of these clients can be tracked by the server. [if the
client has terminated this will throw remote exception and that clients
details can be removed from the server]
The small event object transmitted will be an identifier that gives an
attribute such that the client can determine if its copy has changed, if so
it can request the model object itself.

2/ The client will poll the server, say every 30secs.  It will generate a
request object similar to the event in 1/ above and the server will check if
it has a newer version, if it has it will return it.

Does this make sense?
Am I being naive in anyway?
I realise that I have to make the decision between the two myself by
weighing up more than I've mentioned.
I'm guessing that 1 - 5 % of polls will be fruitful.

I have read that objects should not contain primary keys (ie when they are
derived from DBMS mapping)
I'm guessing that this is because an implementation of equals will serve
this purpose.
But are there any detrimental effects from doing this? My identifier
(event/request) object was going to contain this.

TIA
--
Mike W