Continuing discussions from:
Brief summary: the Atom Feed module built for Sync 2 copy/pasted code from the Event module, because the asynchronous-after-the-transaction event delivery provided by that module wasn’t sufficient. Therefore we’ve been trying to figure out how to make the Event module support the Atom Feed use case.
Taking a step back, I think there are two general use cases that we should be seeking to address:
- Immediate notification of database changes, so that a listener can also take some action within the same DB transaction (and possibly roll it back).
- this is for low-level sorts of activities, and probably has performance implications too
- Basically this is for use cases where you want a hibernate interceptor, but it would be nice if the hibernate interceptor logic could be written just once and others could just get callbacks from one place.
- Notification after application events have happened (without the ability to cancel that event)
- This is the traditional Event paradigm
- Example: get notified every time a new patient is registered; get notified when a new order is created
- (wearing my ThoughtWorks hat we tend to say that you should listen on an atom feed instead of doing this paradigm, but I won’t go into that now)
I think there’s a simple solution, based on our current state:
- Introduce a new module named “dbchangenotification”, which has a hibernate interceptor, and gives a mechanism to get a callback just before the transaction is closed. This callback mechanism would have much simpler semantics than a hibernate interceptor.
- obviously the module needs a better name than this
- really this ought to go in openmrs-core, but that would happen later
- the event module basically stays as-is, but it could depend on this new module instead of defining its own hibernate interceptor
Pro: have a standard but simpler mechanism for triggering on changes to domain objects; it’s possible to build a lighter-weight OpenMRS distro without the event module and ActiveMQ while still using this.
Con: the RefApp (and/or anything that depends on registrationcore) would have one more module
@wyclif, you seem to think that there are additional meaningful use cases beyond the two I mentioned above. Can you say more about that, and what the real-world scenario is for them?
The alternatives approaches I see are:
- Say it’s okay for atomfeed to have a hibernate interceptor, as it’s pretty integral to what that module does. (I.e. the atomfeed and event modules can both stay exactly as they are today.)
- The new module that I describe above is instead made a part of the Event module (thus making that module a bit larger)
Irrespective of any of this, we should update the event module to have the latest version of ActiveMQ rather than the very old one that’s there today.