Grouper Developers Forum

[Tom Barton <>]

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…
>
> http://www.hibernate.org/hib_docs/reference/en/html/events.html

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).

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