Much appreciated. I have to think about it for a bit obviously :-)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 July 2003 22:11 To: OJB Users List Subject: Re: Turning off the cache or marking chached objects stale Hi again Paul, 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
