Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] RE: refactor the DAOs

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] RE: refactor the DAOs

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] RE: refactor the DAOs
  • Date: Thu, 19 Jun 2008 08:57:20 +0100

I've suggested to Chris, off list, that we don't need to use callbacks for the first GrouperSession.start invocation. This should cover common coding requirements. If you then need to start a new GrouperSession and do some work you would use the callback - otherwise a second GrouperSession.start (without a GrouperSession.stop) would throw and IllegalStateException.

I'm all for changing the API so that we then no longer need to keep passing GrouperSession as an argument to lots of methods, however, this is a change which if introduced without deprecation would break all existing code which calls the API - so, in order to upgrade, you would have to change all custom code and we would need to update the UI, WS, GSH and LDAPPC at the same time.


--On 18 June 2008 05:38 -0400 Chris Hyzer

Ok, that wasn't too big of a deal, I refactored per my previous email and
all unit tests pass.

The next step is change the data layer a little more.

Right now if the hook gets GroupDTO, it would be nice to get back to the
Group object so that all the group members can be listed.

The Group object has two fields, the GrouperSession (who to run queries
as for security), and the GroupDTO. So if the GroupDTO knows the
GrouperSession, then we can get to a Group object. Since the GroupDTO
can be cached (and since in OO it doesn't belong anyway), we don't want
the DTO to have a reference to GrouperSession. So...

The proposal is to do a ThreadLocal and inverse of control (IOC) on
GrouperSession similar to the way the HibernateSession works with long
running transactions, and not have the Group object keep a reference to
GrouperSession. We need IOC since in ThreadLocals we need to remove it
when it is done.

Existing code would need to be modified


GrouperSession grouperSession = GrouperSession.start(subject); work...


GrouperSession.callbackGrouperSession(subject, new
GrouperSessionHandler() { public Object callback(GrouperSession
grouperSession) { work...

Then at that point, the business object only has a 1 to 1 reference to
DTO, so we could just get rid of DTO so the hooks would be very easy to
use (you only have to worry about business object, you can list members
with the object you receive, etc).

We could deprecate the existing session strategy, but the problem is if
you don't close your session in the current way you are still good to go.
If you don't close your session with threadlocals (new way), bad things
can happen... so I suggest doing what we did with hibernate long running
transactions and make the switch... but if we want to deprecate and
people will still compile but might or might not work, that fine too. :)

Im not sure this is feasible, so the first thing to do is try it and see
if there are problems...

Anyone have existing code that this would break or anyone have other
objections? Let me know thoughts asap.


-----Original Message-----
From: Chris Hyzer
Sent: Monday, June 16, 2008 10:07 PM
To: Grouper Dev
Subject: refactor the DAOs


Gary and I were discussing how the Grouper data layer works.

Currently it is a business object (e.g. Group) which talks to (and
delegates to) a DTO bean (e.g. GroupDTO), which talks to and lazily
delegates to a DAO bean (e.g. GroupDAO interface which is implemented
by Hib3GroupDAO).

In doing hooks, there are some complications with this approach:

1. different hooks have access to different object layers, and not all
object layers have references to each other
2. when doing things like getting diffs of what has changed, the DB
state of the object needs to be stored, but this is in the DAO at the
time of Hibernate, and that particular DAO is not kept around, another
is created when needed again, so the DB state needs to be propagated:
DAO -> DTO -> Business object -> DTO -> DAO

Needless to say I am trying to simplify a little bit.

My idea was to cut out a layer or two. This would be a decent amount
of (re)work. Gary's idea is to take the bean part out of the DAO, and
make it a singleton which is only responsible for data access queries
(which return DTO's). The DTO's would hold the state of the object.

I checked it out briefly, and Gary's idea would not require a lot of
code changes, and would simplify things, so I agree this is how we
should proceed.

I will do this and see how it goes. Let me know asap if anyone
disagrees or would like to discuss. These objects weren't public
before and they are an implementation detail, else I would wait for a
call, but thought I would mention it on the list. :)


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page