On Sep 8, 2014 9:59 AM, "Emmanuel Bernard" <emman...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
