RE: auditing mapped classes
afterLookup is fired regardless of whether it was cached or from the database. >-Original Message- >From: Ebersole, Steven [mailto:[EMAIL PROTECTED] >Sent: 26 February 2003 14:31 >To: 'OJB Users List' >Subject: RE: auditing mapped classes > > >The PersistenceBrokerListener could definitely be used as a >start for this >functionality along the lines you mention. A quick question, >how does using >caching affect the afterLookup event? Is this event only fired when an >object is materialized from the DB, or after any lookup (regardless of >whether found in cache or loaded from DB)? > >The transaction knowledge depends on what you are trying to >accomplish. For >example, another thing I need to perform is that if an object changed, >update its audit fields. However, a txn-commiting type event >is (at least >has been) problematic because my event processing needs to be >included in >the transaction. And even for the audtiting requirment I >mentioned earlier, >as long as the event-hub and/or audting gateway is >transactional, I don't >think knowledge of the PB transaction is necessarily required; >at least for >my specs and given my limited understanding of OJB. > >My plan would basically be to: >1) On afterLookup event, store a deep copy of the object just read; >2) On beforeStore calculate the instance's changeset (using the TopLink >term); >if (changes occurred) >Publish change to the domain-event-hub >reset the domain objects audit fields >else >Do nothing > > >Or I could just leave the journalling as part of the domain objects >themselves. I'll have to think about this some more. > > > >|-Original Message- > |From: Charles Anthony [mailto:[EMAIL PROTECTED] >|Sent: Wednesday, February 26, 2003 2:28 AM >|To: 'OJB Users List' >|Subject: RE: auditing mapped classes >| >| >|Hi, >| >|I think it *may* be possible using the >|PersistenceBrokerListener mechanism. >|The PersistenceBrokerListener is an interface, >|implementations of which can >|be added to a persistence broker. >|It has call-backs for when objects are "looked up", and >|when they are >|"stored" (among other events). >| >|You could "copy" the objects attributes after looking up, >|and compare them >|when they are stored. >| >|This is essentially what the ODMG layer is doing, but in a >|different way. >| >|The one caveat would be (and I need to solve this for a >|problem myself) is >|knowing when the PersistenceBroker transaction is >|committed/rolled back - >|that is really when you would want to compare the >|attributes of stored >|objects. This should be possible by adding the appropriate > |callbacks to the > |PBListener mechanism. >| >|HTH a little, >| >|Cheers, >| >|Charles. >| >| >|>-Original Message- >|>From: Ebersole, Steven [mailto:[EMAIL PROTECTED] >|>Sent: 25 February 2003 20:39 >|>To: 'OJB Users List' >|>Subject: RE: auditing mapped classes >|> >|> >|>I think ideally this fits as low on the persistence mechanism >|>as possible >|>(i.e., the DB). However, the thought of implementing >|this as a web of >|>triggers, when I have a nice Object layer directly above, just >|>seems silly. >|> >|>I impetus behind this is that I am writing a thin interface >|>layer over (and >|>hiding) the particular O/R implementation; much like you have >|>spoken about >|>on this list quite a few times. Currently Castor is built and >|>OJB is a work >|>in progress and TopLink is on the horizon. Castor has no >|such concept, >|>although they too have the callback mechanism. This is what >|>lead me to the >|>InvocationHandler/Map/Journaler approach. Basically the >|domain objects >|>extend a base, which instantiates a >|InvocationHandler-wrapped Map and >|>listens for persistence callbacks. The Map also has an attached >|>"Journaller" responsible for maintaining changes state of >|the object >|>(similiar to the DB concept). At transaction start, it >|>initiailizes the >|>Journaler and begins recording changes. At commit, it >|>notifies an EventHub >|>which is responsible for in turn notifying the >|integration and
RE: auditing mapped classes
The PersistenceBrokerListener could definitely be used as a start for this
functionality along the lines you mention. A quick question, how does using
caching affect the afterLookup event? Is this event only fired when an
object is materialized from the DB, or after any lookup (regardless of
whether found in cache or loaded from DB)?
The transaction knowledge depends on what you are trying to accomplish. For
example, another thing I need to perform is that if an object changed,
update its audit fields. However, a txn-commiting type event is (at least
has been) problematic because my event processing needs to be included in
the transaction. And even for the audtiting requirment I mentioned earlier,
as long as the event-hub and/or audting gateway is transactional, I don't
think knowledge of the PB transaction is necessarily required; at least for
my specs and given my limited understanding of OJB.
My plan would basically be to:
1) On afterLookup event, store a deep copy of the object just read;
2) On beforeStore calculate the instance's changeset (using the TopLink
term);
if (changes occurred)
Publish change to the domain-event-hub
reset the domain objects audit fields
else
Do nothing
Or I could just leave the journalling as part of the domain objects
themselves. I'll have to think about this some more.
|-Original Message-
|From: Charles Anthony [mailto:[EMAIL PROTECTED]
|Sent: Wednesday, February 26, 2003 2:28 AM
|To: 'OJB Users List'
|Subject: RE: auditing mapped classes
|
|
|Hi,
|
|I think it *may* be possible using the
|PersistenceBrokerListener mechanism.
|The PersistenceBrokerListener is an interface,
|implementations of which can
|be added to a persistence broker.
|It has call-backs for when objects are "looked up", and
|when they are
|"stored" (among other events).
|
|You could "copy" the objects attributes after looking up,
|and compare them
|when they are stored.
|
|This is essentially what the ODMG layer is doing, but in a
|different way.
|
|The one caveat would be (and I need to solve this for a
|problem myself) is
|knowing when the PersistenceBroker transaction is
|committed/rolled back -
|that is really when you would want to compare the
|attributes of stored
|objects. This should be possible by adding the appropriate
|callbacks to the
|PBListener mechanism.
|
|HTH a little,
|
|Cheers,
|
|Charles.
|
|
|>-Original Message-
|>From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
|>Sent: 25 February 2003 20:39
|>To: 'OJB Users List'
|>Subject: RE: auditing mapped classes
|>
|>
|>I think ideally this fits as low on the persistence mechanism
|>as possible
|>(i.e., the DB). However, the thought of implementing
|this as a web of
|>triggers, when I have a nice Object layer directly above, just
|>seems silly.
|>
|>I impetus behind this is that I am writing a thin interface
|>layer over (and
|>hiding) the particular O/R implementation; much like you have
|>spoken about
|>on this list quite a few times. Currently Castor is built and
|>OJB is a work
|>in progress and TopLink is on the horizon. Castor has no
|such concept,
|>although they too have the callback mechanism. This is what
|>lead me to the
|>InvocationHandler/Map/Journaler approach. Basically the
|domain objects
|>extend a base, which instantiates a
|InvocationHandler-wrapped Map and
|>listens for persistence callbacks. The Map also has an attached
|>"Journaller" responsible for maintaining changes state of
|the object
|>(similiar to the DB concept). At transaction start, it
|>initiailizes the
|>Journaler and begins recording changes. At commit, it
|>notifies an EventHub
|>which is responsible for in turn notifying the
|integration and audting
|>gateways.
|>
|>Then, on doing some advanced scouting on the TopLink stuff, I
|>noticed the
|>changeset stuff and thought it would be really, really nice to
|>have this
|>refactored out of the domain classes theselves. I guess, I
|>wasn't thinking
|>of the processing integrated into the O/R layer, just a
|callback-level
|>interface so that parallel systems could basically
|register interest in
|>changes.
|>
|>With the OJB persistence wrapping, I was hoping to utilize the
|>PB approach.
|>But it sounds like this will not be possible.
|>
|>
|>
|>|-Original Message-
RE: auditing mapped classes
Hi, I think it *may* be possible using the PersistenceBrokerListener mechanism. The PersistenceBrokerListener is an interface, implementations of which can be added to a persistence broker. It has call-backs for when objects are "looked up", and when they are "stored" (among other events). You could "copy" the objects attributes after looking up, and compare them when they are stored. This is essentially what the ODMG layer is doing, but in a different way. The one caveat would be (and I need to solve this for a problem myself) is knowing when the PersistenceBroker transaction is committed/rolled back - that is really when you would want to compare the attributes of stored objects. This should be possible by adding the appropriate callbacks to the PBListener mechanism. HTH a little, Cheers, Charles. >-Original Message- >From: Ebersole, Steven [mailto:[EMAIL PROTECTED] >Sent: 25 February 2003 20:39 >To: 'OJB Users List' >Subject: RE: auditing mapped classes > > >I think ideally this fits as low on the persistence mechanism >as possible >(i.e., the DB). However, the thought of implementing this as a web of >triggers, when I have a nice Object layer directly above, just >seems silly. > >I impetus behind this is that I am writing a thin interface >layer over (and >hiding) the particular O/R implementation; much like you have >spoken about >on this list quite a few times. Currently Castor is built and >OJB is a work >in progress and TopLink is on the horizon. Castor has no such concept, >although they too have the callback mechanism. This is what >lead me to the >InvocationHandler/Map/Journaler approach. Basically the domain objects >extend a base, which instantiates a InvocationHandler-wrapped Map and >listens for persistence callbacks. The Map also has an attached >"Journaller" responsible for maintaining changes state of the object >(similiar to the DB concept). At transaction start, it >initiailizes the >Journaler and begins recording changes. At commit, it >notifies an EventHub >which is responsible for in turn notifying the integration and audting >gateways. > >Then, on doing some advanced scouting on the TopLink stuff, I >noticed the >changeset stuff and thought it would be really, really nice to >have this >refactored out of the domain classes theselves. I guess, I >wasn't thinking >of the processing integrated into the O/R layer, just a callback-level >interface so that parallel systems could basically register interest in >changes. > >With the OJB persistence wrapping, I was hoping to utilize the >PB approach. >But it sounds like this will not be possible. > > > >|-Original Message- >|From: Thomas Mahler [mailto:[EMAIL PROTECTED] >|Sent: Tuesday, February 25, 2003 2:16 PM >|To: OJB Users List >|Subject: Re: auditing mapped classes >| >| >|Hi STeven, >| >|Ebersole, Steven wrote: >|> I'll take silence as a no... >| >|In my case silence just means "tom did not find the time >to answer >|yet... or even worse he did miss the original posting..." >| >|> >|> |-Original Message- >|> |From: Ebersole, Steven >[mailto:[EMAIL PROTECTED] >|> |Sent: Monday, February 24, 2003 10:35 AM >|> |To: OJB Users List (E-mail) >|> |Subject: auditing mapped classes >|> | >|> | >|> |I was wondering if OJB has built-in support for auditing >|> |state changes in >|> |the classes which are mapped under its control. What I am >|> |thinking of is >|> |something along the lines of TopLink's changeset concept. >| >|depends on the API we are talking about: >|- For OJB-PersistenceBroker it's a clear no. >|- For OJB-JDO it's a clear yes. The JDO spec does require JDO >|implementations to do this. The required code is injected >into the >|persistent classes by bytecode enhancement. >|- For OJB-ODMG it's a clear "partially": >|in our ODMG implementation all instances managed by a >|transaction are >|inserted into so called ObjectEnvelope objects. The >ObjectEnvelope >|implements the contract between a persistent instance and >|the ODMG ty >|management. It contains a snapshot of the persistent >|instance of the >|point in time when it was registered. >|This Envelope is use on TX commit to detect all changes to the >|persistent instance. >|But as we do no bytecode enhancement in ODMG, we don't get &g
RE: auditing mapped classes
I think ideally this fits as low on the persistence mechanism as possible
(i.e., the DB). However, the thought of implementing this as a web of
triggers, when I have a nice Object layer directly above, just seems silly.
I impetus behind this is that I am writing a thin interface layer over (and
hiding) the particular O/R implementation; much like you have spoken about
on this list quite a few times. Currently Castor is built and OJB is a work
in progress and TopLink is on the horizon. Castor has no such concept,
although they too have the callback mechanism. This is what lead me to the
InvocationHandler/Map/Journaler approach. Basically the domain objects
extend a base, which instantiates a InvocationHandler-wrapped Map and
listens for persistence callbacks. The Map also has an attached
"Journaller" responsible for maintaining changes state of the object
(similiar to the DB concept). At transaction start, it initiailizes the
Journaler and begins recording changes. At commit, it notifies an EventHub
which is responsible for in turn notifying the integration and audting
gateways.
Then, on doing some advanced scouting on the TopLink stuff, I noticed the
changeset stuff and thought it would be really, really nice to have this
refactored out of the domain classes theselves. I guess, I wasn't thinking
of the processing integrated into the O/R layer, just a callback-level
interface so that parallel systems could basically register interest in
changes.
With the OJB persistence wrapping, I was hoping to utilize the PB approach.
But it sounds like this will not be possible.
|-Original Message-
|From: Thomas Mahler [mailto:[EMAIL PROTECTED]
|Sent: Tuesday, February 25, 2003 2:16 PM
|To: OJB Users List
|Subject: Re: auditing mapped classes
|
|
|Hi STeven,
|
|Ebersole, Steven wrote:
|> I'll take silence as a no...
|
|In my case silence just means "tom did not find the time to answer
|yet... or even worse he did miss the original posting..."
|
|>
|> |-Original Message-
|> |From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
|> |Sent: Monday, February 24, 2003 10:35 AM
|> |To: OJB Users List (E-mail)
|> |Subject: auditing mapped classes
|> |
|> |
|> |I was wondering if OJB has built-in support for auditing
|> |state changes in
|> |the classes which are mapped under its control. What I am
|> |thinking of is
|> |something along the lines of TopLink's changeset concept.
|
|depends on the API we are talking about:
|- For OJB-PersistenceBroker it's a clear no.
|- For OJB-JDO it's a clear yes. The JDO spec does require JDO
|implementations to do this. The required code is injected into the
|persistent classes by bytecode enhancement.
|- For OJB-ODMG it's a clear "partially":
|in our ODMG implementation all instances managed by a
|transaction are
|inserted into so called ObjectEnvelope objects. The ObjectEnvelope
|implements the contract between a persistent instance and
|the ODMG ty
|management. It contains a snapshot of the persistent
|instance of the
|point in time when it was registered.
|This Envelope is use on TX commit to detect all changes to the
|persistent instance.
|But as we do no bytecode enhancement in ODMG, we don't get
|triggered,
|when user code modifies an instance under ODMG control.
|
|
|> |Currently I have a base domain class which is responsible
|> |for tracking these
|> |property changes, and then publishing notification to an
|> |event manager which
|> |brokers those notifications to auditing and
|integration gateways.
|> |
|> |In TopLink, I could utilize its EventManager and
|DescriptorEvent to
|> |externalize this whole process (basically refactoring it
|> |out of the domain
|> |classes). And basically, I was just wondering if
|> |something similiar already
|> |exists in OJB.
|
|No there is nothing that maps directly to this concepts.
|We only provide
|simple instance callback mechanisms to inform instances about
|persistence operations going on.
|
|But (apart from the bytecode enhanced JDO) we do not
|interfere with user
|code accessing attributes.
|
|
|Do you think this is an important functionality for an O/R layer?
|Where (which OJB layer) could you imagine to fit it in?
|Would a generalized bytecode-enhancement or an aspect
|weaving mechanism
|be a possible solution?
|
|cheers,
|Thomas
|
|
|
|> |
|> |
|> |
|> |
|&g
Re: auditing mapped classes
Hi STeven, Ebersole, Steven wrote: I'll take silence as a no... In my case silence just means "tom did not find the time to answer yet... or even worse he did miss the original posting..." |-Original Message- |From: Ebersole, Steven [mailto:[EMAIL PROTECTED] |Sent: Monday, February 24, 2003 10:35 AM |To: OJB Users List (E-mail) |Subject: auditing mapped classes | | |I was wondering if OJB has built-in support for auditing |state changes in |the classes which are mapped under its control. What I am |thinking of is |something along the lines of TopLink's changeset concept. depends on the API we are talking about: - For OJB-PersistenceBroker it's a clear no. - For OJB-JDO it's a clear yes. The JDO spec does require JDO implementations to do this. The required code is injected into the persistent classes by bytecode enhancement. - For OJB-ODMG it's a clear "partially": in our ODMG implementation all instances managed by a transaction are inserted into so called ObjectEnvelope objects. The ObjectEnvelope implements the contract between a persistent instance and the ODMG ty management. It contains a snapshot of the persistent instance of the point in time when it was registered. This Envelope is use on TX commit to detect all changes to the persistent instance. But as we do no bytecode enhancement in ODMG, we don't get triggered, when user code modifies an instance under ODMG control. |Currently I have a base domain class which is responsible |for tracking these |property changes, and then publishing notification to an |event manager which |brokers those notifications to auditing and integration gateways. | |In TopLink, I could utilize its EventManager and DescriptorEvent to |externalize this whole process (basically refactoring it |out of the domain |classes). And basically, I was just wondering if |something similiar already |exists in OJB. No there is nothing that maps directly to this concepts. We only provide simple instance callback mechanisms to inform instances about persistence operations going on. But (apart from the bytecode enhanced JDO) we do not interfere with user code accessing attributes. Do you think this is an important functionality for an O/R layer? Where (which OJB layer) could you imagine to fit it in? Would a generalized bytecode-enhancement or an aspect weaving mechanism be a possible solution? cheers, Thomas | | | | |Steve Ebersole |IT Integration Engineer |Vignette Corporation |Office: 512.741.4195 |Mobile: 512.297.5438 | |Visit http://www.vignette.com | |--- |-- |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]
RE: auditing mapped classes
I'll take silence as a no... |-Original Message- |From: Ebersole, Steven [mailto:[EMAIL PROTECTED] |Sent: Monday, February 24, 2003 10:35 AM |To: OJB Users List (E-mail) |Subject: auditing mapped classes | | |I was wondering if OJB has built-in support for auditing |state changes in |the classes which are mapped under its control. What I am |thinking of is |something along the lines of TopLink's changeset concept. | |Currently I have a base domain class which is responsible |for tracking these |property changes, and then publishing notification to an |event manager which |brokers those notifications to auditing and integration gateways. | |In TopLink, I could utilize its EventManager and DescriptorEvent to |externalize this whole process (basically refactoring it |out of the domain |classes). And basically, I was just wondering if |something similiar already |exists in OJB. | | | | |Steve Ebersole |IT Integration Engineer |Vignette Corporation |Office: 512.741.4195 |Mobile: 512.297.5438 | |Visit http://www.vignette.com | |--- |-- |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]
