Paul Worrall wrote:
Thanks Thomas,
Looks like I have a design problem. Yes, the subscriber updates the state directly in the DB. The state that it changes is never changed by the Publisher so I thought the database would prevent corruption at the database level.
There won't be a data corruption, but the Publisher may have an incorrect view of the data.
From what you say I have at least two options:-
1) To make sure the Publisher objects are updated I could specifically remove them from cache after every time I use them on the publisher side?
2) Or I could extend the architecture to pass the updated objects back up through the middleware on a 'reverse queue' and update the database from the Publisher side.
I think both option are viable.
1) has the advantage that it easier to implement. The disadvantage is that you have no direct means to notify the publisher that data has changed. But maybe this is not required in your situation.
2) is more complex to implement, The gain is immediate propagation of data changes.
It really depends on your requirements if you really need 2) or if 1) could be sufficient.
cheers, Thomas
What do you think?
TIA
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 July 2003 18:43
To: OJB Users List
Subject: Re: Turning off the cache or marking chached objects stale
Hi Paul,
Paul Worrall wrote:
Hi,
I am passing a serialized object through a JMS middleware. This is an object persisted using OJB and the object ends up being 'published' from one JVM and 'subscribed' to from another JVM. I presume because of the caching of persistent objects in OJB changes by the subscriber to the objects persistent state are not being reflected in the publishers side.
Mhh, how is the publisher informed about the changes? Do send the modified objects back? Or does the subscriber write to the same DB as the publisher?
Do I have to turn the caching off to get these database changes to be reflected and how do I do that.
So it seems the subscriber is also updating the db, correct?
In this case you could use optimistic locking to avoid data corruption if the publisher again tries to write to the db.
But this will not automatically refresh the the publisher side instance!
You have to do it manually by: broker.removeFromCache(instance);
Identity oid = new Identity(instance, broker); instance =
broker.getObjectByIdentity(oid);
Or is there some mechanism that marks cached objects as stale when the state changes in the database without
going through the OJB. And how do I do that?
No there is no such mechanism.
cheers, Thomas
Kind regards,
Paul Worrall
Architect | Director
Apcentric Limited
The Soft Science of J2EE Deployment
m: +44 (0) 77 1133 0213
w: < <http://www.apcentric.com/> http://www.apcentric.com/> <outbind://10/www.apcentric.com> www.apcentric.com
Any opinions expressed in the email are those of the individual and not
necessarily of the company. This email and any files transmitted with
it are confidential and solely for the use of the intended recipient.
It may contain material protected by attorney-client privilege. If you
are not the intended recipient or person responsible for delivering to
the intended recipient, be advised that you have received this email in
error and that any use is strictly prohibited. If you have received
this email in error please notify the IT manager.
Kind regards,
Paul Worrall
Commercial Director
MJW Handling Services Limited
Rising to the Challenge
t: +44 (0) 870 204 1902
m: +44 (0) 77 1133 0213 w: www.mjw-handling.co.uk
Any opinions expressed in the email are those of the individual and not
necessarily of the company. This email and any files transmitted with
it are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If
you
are not the intended recipient or person responsible for delivering to
the intended recipient, be advised that you have received this email
in
error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
