You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Paul Worrall <pa...@apcentric.com> on 2003/07/11 23:27:33 UTC
Turning off the cache or marking chached objects stale
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.
Do I have to turn the caching off to get these database changes to be
reflected and how do I do that. 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?
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.
RE: Turning off the cache or marking chached objects stale
Posted by Paul Worrall <pa...@apcentric.com>.
Much appreciated.
I have to think about it for a bit obviously :-)
-----Original Message-----
From: thma32@web.de [mailto:thma32@web.de]
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: thma32@web.de [mailto:thma32@web.de]
> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Turning off the cache or marking chached objects stale
Posted by Thomas Mahler <th...@web.de>.
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: thma32@web.de [mailto:thma32@web.de]
> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: Turning off the cache or marking chached objects stale
Posted by Paul Worrall <pa...@apcentric.com>.
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.
>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.
What do you think?
TIA
-----Original Message-----
From: thma32@web.de [mailto:thma32@web.de]
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Turning off the cache or marking chached objects stale
Posted by Thomas Mahler <th...@web.de>.
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org