[hibernate-dev] Advice - cyclic event handling

[Emmanuel Bernard]

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?

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.

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