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-----
|> |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
|> |
|> |
|> |
|> |> |
|> |> |
|> |> |
|> |> |
|> |> |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]
|> |
|>
|>----------------------------------------------------------
|-----------
|>To unsubscribe, e-mail: [EMAIL PROTECTED]
|>For additional commands, e-mail: [EMAIL PROTECTED]
|>
|
|
|This email and any attachments are strictly confidential
|and are intended
|solely for the addressee. If you are not the intended
|recipient you must
|not disclose, forward, copy or take any action in reliance
|on this message
|or its attachments. If you have received this email in
|error please notify
|the sender as soon as possible and delete it from your
|computer systems.
|Any views or opinions presented are solely those of the
|author and do not
|necessarily reflect those of HPD Software Limited or its
|affiliates.
|
| At present the integrity of email across the internet
|cannot be guaranteed
|and messages sent via this medium are potentially at risk.
| All liability
|is excluded to the extent permitted by law for any claims
|arising as a re-
|sult of the use of this medium to transmit information by or to
|HPD Software Limited or its affiliates.
|
|
|
|-----------------------------------------------------------
|----------
|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]
