[hibernate-dev] Advice - cyclic event handling

Steve Ebersole steve at hibernate.org
Mon Sep 8 17:59:23 EDT 2014


On Sep 8, 2014 9:59 AM, "Emmanuel Bernard" <emmanuel at hibernate.org> wrote:
>
> Throwing off some ideas.
>
> Have you thought about an entity A whose composed id is made of the id of
> two different entities B and C.
> A would enlist to B and C completion and would need to record when it
> receives the first event and process everything when the second event
> arrives?

Yes, the code already accounts for this essentially in the exact way you
describe.

> A way around your problem could be to use index lookups instead of
> iterators to process the watch list. That way you can set a specific
> index to null when it is processed without affecting the subsequent
> indexes nor raise a CME. That would be close to a ring buffer
> implementation I suppose.

Right.  Depending on what you mean by indexed, this is what I mentioned in
regards to regsitering the listeners keyed by the entity(s) they are
interested in (given the id case).

>
> Emmanuel
>
> On Tue 2014-09-02 13:41, Steve Ebersole wrote:
> > As part of the metamodel work, one of things I am working on is
redesigning
> > the old notion of a "second pass" to be more efficient.  For those not
> > familiar, this represents a piece of processing that needs to be delayed
> > until after another piece of processing is done.  For example,
processing a
> > composite identifier metadata for an entity might depend on the
identifier
> > metadata for another entity being processed first.
> >
> > "second pass" was essentially one big bucket.  In the new design I am
> > trying to categorize or segment these things better, so we have
different
> > buckets (one for identifier metadata completion, one for attribute Type
> > metadata completion, etc).
> >
> > Not to get too involved, but essentially a bucket is a List of
"watchers"
> > for specific "happenings" (I think of them as events, but am trying to
> > avoid that terminology for now).  E.g., take the "identifier metadata
> > completion" bucket.  As we complete the binding of the identifier
metadata
> > for an entity, we fire off a notification of that happening.  The
watchers
> > can then react to that notification.
> >
> > The implementation of this is a List of watchers, as I said, which is
> > iterated over for each notification.  So here comes the trickiness.  As
> > each watcher is finished it needs to be removed from the list of
watchers.
> >  And a watcher could in turn kick off a new notification (for it
completing
> > whatever it represents).  So in the initial impl I ran into
> > ConcurrentModificationException problems.
> >
> > I went ahead and made it work just to move forward.  But I wanted to
circle
> > back and design this "right"; so I wanted to get others involved to see
if
> > anyone had thoughts or better ideas.
> >
> > Here is a simple example to use as a basis for discussion:  consider the
> > entity Customer and Order.  Customer has a simple identifier, whereas
Order
> > has a composite identifier made up of (1) FK to Customer and (2) a order
> > number.  We need the identifier metadata for Customer to be completely
> > bound before we can process the identifier metadata for Order.  That is
the
> > crux of the problem to be solved.  Its an ordering concern.  If the
> > metadata for the Customer entity is processed first, no big deal.  But
of
> > course we can't really control that (putting the onus back on the user
here
> > is fugly).  So we need to account for the case where metadata for the
Order
> > entity is processed first.  This kind of timing thing is the reason for
> > second passes and these new notifications.  The idea in the new design
is
> > that we would register a watcher for Order which waits for the
notification
> > that Customer identifier metadata has been finished.  As the identifier
for
> > each entity is completed, that process fires off a notification of that
> > fact.  So as the identifier metadata for Customer is finished, the
process
> > fires off a notification which makes its way back to the watcher for
Order.
> >  Processing can now bind the identifier metadata for Order, and in turn
> > fire off its notification.
> >
> > The trouble here, in the iteration impl, is that we are still iterating
> > over the "identifier metadata completion" notification, so there is an
> > active iterator over the list.  When performing the Order-watcher
> > processing, since it no longer needs to watch, we would ideally remove
it.
> >  Initially I had simply exposed a deregistration method that removed the
> > watcher from the list, but that ran into the problems with CME.  What I
do
> > currently instead is to expose a method on the watcher contract for the
> > watcher to say whether its work is done, and if so use the Iterator to
> > remove it.  That works, just not sure its the best option.
> >
> > Another consideration is the iteration over non-interested watchers.
This
> > may be a non-issue, not sure yet.  Currently watchers simply register as
> > being interested in identifier metadata completion notifications, not
> > notifications for completion of identifier metadata for specific
entity(s).
> >  So on the con side, the List would become a Map and we'd need a key
> > object.  On the plus side we'd avoid the iteration and CME problems
> > altogether.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list