Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] changelog implementation sketch

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] changelog implementation sketch

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Tom Zeller <>, "GW Brown, Information Systems and Computing" <>, Grouper Dev <>, "" <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Tue, 03 Jun 2008 09:14:38 -0500

Chris Hyzer wrote:
When is the notification going to be sent to the external system. I hope it is pulled off a queue in the DB and processed that way, and not real-time or asynchronous from a java hook, right? Since that is the reliability aspect.

And more importantly, the consistency aspect. That is, since there will generally be several JVMs running grouper, the only singular element, the DB, is essential to achieve consistent notifications.

We *could* use a post-commit hook to signal a notification system to go check the DB and determine if it should do some notifying. That would facilitate real-time notification, though without guarantees.

In order for the notification to be sure it is time to notify, a commit must take place of the grouper data. And in order for that notification to be reliably in the DB, it must be put in the grouper db, in the same transaction as the data commit. Then it can be pulled off the audit table (and maybe a table which keeps track of the last_edited date that each notification type is up to), and sent to the external system, then that last_edited date or state keeper can be updated…
If we really want real time, I think we could use a hibernate session interceptor or event as a first pass…

I'm reluctant to have us build a notification system. There are many 3rd party tools. Should we, at least for our first go, just integrate with one such open source product, at least to illustrate how that can be done?

This notion of serialization and point-in-time is definitely
more powerful and useful, but also more complex and might be less performant and require more storage… if that turns out to be the case, maybe it could be an option (the option being either to serialize or to just use grouper data but still have notifications/auditing available) J

Perfect serialization of transactions will be hard to achieve, in the sense of enforcing a sequence on transactions so that it is impossible to produce an inconsistent image of the DB. That would take some serious structural rethinking, I suspect. But we can at least apply a deterministic monotone increasing serial number to each transaction and use that to supply an order to notifications. For example, a lockable DB table used to handout a new serial number as part of creation of a transaction. This will reduce opportunity for inconsistency, and is essential to enable roll-back, replayability, and point-in-time types of applications (and I'm not suggesting that we build those applications, just enable use of those capabilities in 3rd party tools).

fn:Tom Barton
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
title:Sr. Director - Integration
tel;work:+1 773 834 1700

Archive powered by MHonArc 2.6.16.

Top of Page