Grouper Developers Forum

[Chris Hyzer <>]

Gary put comments on my hooks page about transactions and notifications.

 

https://wiki.internet2.edu/confluence/display/GrouperWG/Hooks+simple

 

It makes this whole thing very complicated… if the actions happens in a long running transaction, and you want to be notified at the end, there are a few issues:

 

1.       It is a different architecture than we had been discussing since we need to know about the action at the time of the (successful) commit.  Perhaps using Hibernate’s events could do the trick, but you don’t have any object model anymore, you just have a list of column data for one table

2.       Like Gary points out, if the thing you are updating external to grouper fails, how do you log that and catch up later (e.g. if you are calling a web service, and there is a network issue)

3.       There are lots of different producers of events (UI, WS, extensions e.g. gsh, and direct db edits [granted they shouldn’t]).  Must make sure the notification hooks are registered everywhere, and test them to make sure they are firing everywhere (seems tedious / risky)

 

Lets take the use case of writing your own ldappc via notifications (something we will start out with at penn).  We want to know about new members, memberships, and groups.  We will just make 3 tables with the id’s and timestamps of when these change:

 

select * from ldap_change_memberships lcm where rownum < 4 order by lcm.LAST_UPDATED desc

MEMBERSHIP_UUID      LAST_UPDATED

cd5f23d2-a8c8-44c0-a8b1-a3c3210da3c5                5/8/2008 1:21:37.569272 PM

74710fee-40b2-48e4-a8dd-b750876bc4ea             5/8/2008 1:21:37.462896 PM

f2cf6b80-377c-41c3-981d-0eb9274dc74a                5/8/2008 1:21:36.076199 PM

 

On the grouper tables I have some simple triggers that check for diffs and insert to the change tables (and delete old records since all the daemon cares about is the most recently changed record).

 

Then we also have friendly views for the daemon to use to query the data:

 

select gmv.GROUP_NAME, gmv.SUBJECT_ID, gmv.SUBJECT_SOURCE, gmv.MSHIP_TYPE from grouper_memberships_v gmv where rownum < 4

GROUP_NAME                                 SUBJECT_ID                        SUBJECT_SOURCE           MSHIP_TYPE

 

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

 

Then a daemon will run every 5 minutes to push the new data to ldap, and delete the record from the change table when done.

 

So this is all transactional, nothing can slip by (since trigger), and nothing can happen wrong if ldap update fails.

 

Triggers are DB specific, and it requires different tables for each notification type.

 

For notifications, grouper could provide:

 

1.       If you have certain table structures for last_updated dates (perhaps with name prefixes to support multiple)

2.       We could populate with Java hooks (perhaps not reliable per discussion above), or you could do triggers (we could provide examples for certain DB’s) which would be more reliable and probably more performant

3.       We could provide a daemon (e.g. runs every 5 minutes) with callbacks that would process the change tables (based on name prefix), and gives you a callback to take the data and put it somewhere

4.       We could provide a scheduled way to get all data not just the diffs (e.g. daily or weekly or monthly to ensure things are in sync)

 

Just brainstorming here…

 

Thanks,

Chris