Grouper Users - Open Discussion List

[Chris Hyzer <>]

We use dataguard, and use a connect URL like the one below.  Do some testing, 
if one is down and the other is up, you might need to bounce grouper to clear 
out the db pool, not sure...

Thanks,
Chris

-----Original Message-----
From: Peter DiCamillo 
[mailto:]
 
Sent: Thursday, June 09, 2011 2:34 PM
To: Chris Hyzer
Cc: William G. Thompson, Jr.; 

Subject: Re: [grouper-users] Grouper and database failover

Thanks for the information. Sorry for the premature request-- it turns 
out that our DBAs don't have RAC installed, but use Oracle Data Guard. 
So I'll be investigating that, and would be interested in any 
information regarding use of it with Grouper.

Peter

Chris Hyzer wrote:
> Let me say another thing... if you get the latest oracle driver jar, and 
> configure the rac nodes in the connect string of 
> grouper.hibernate.properties, e.g.
> 
> 
> hibernate.connection.url = 
> jdbc:oracle:thin:@(DESCRIPTION=(FAILOVER=on)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=server1.school.edu)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=server2.school.edu)(PORT=1521)))(CONNECT_DATA=(SID=myid)))
> 
> <note, you will need to adjust the failover settings etc>
> 
> Maybe you need to adjust the c3p0 settings so the connections timeout after 
> some short period of time (1 minute?)
> 
> Then I would think when a rac node went down, then the driver would use the 
> other node.  However, on our non-grouper systems, we tried this (maybe it 
> was our c3p0 settings...), but it didn't really work when a rac node 
> failed.  The disadvantage of this is there is not the ONS to proactively 
> tell the driver to take a node out of the pool, however, the hardcoded 
> lists is better then nothing if ONS is not available in Grouper yet.  
> Bottom line, it might be worth a shot to try something like this and see if 
> it works until ONS :)
> 
> Thanks,
> Chris
> 
> -----Original Message-----
> From: Chris Hyzer 
> Sent: Thursday, June 09, 2011 9:24 AM
> To: 'William G. Thompson, Jr.'; Peter DiCamillo
> Cc: 
> 
> Subject: RE: [grouper-users] Grouper and database failover
> 
>> Curious if you (or anyone else) has also consider a NoSQL option for
>> this?  OrientDB looks particularly interesting...
>> http://code.google.com/p/orient/
> 
> The Grouper API heavily depends on a relational database...
> 
>> We're looking at the possibility of configuring Grouper so we can use
>> database failover. We'd like to be able to keep Grouper up during database
>> maintenance, and also in disaster recover situations. We use Grouper with 
>> an
>> Oracle database and with tomcat. We also have some java programs which use
>> the Grouper API and do not run under tomcat.
>>
>> I don't have extensive knowledge of Oracle or jdbc, but some quick Google
>> research suggests that this may be possible, and the recommended method
>> involves using Oracle's Fast Connection Failover mechanism.
>>
>> Does anyone have experience with Grouper and database failover? Are there
>> known reasons why it could or could not be made to work?
> 
> Here is my understanding... FCF requires either oracle's db pool where you 
> configure the ONS and that tells it what servers are in the pool, and which 
> ones to take out when they go down.  You can use FCF with c3p0 (our db 
> pool) if you use the "simple fan" where you write code to listen for ons 
> events and adjust the pool accordingly (sounds less appealing to me).  
> Right now Grouper uses c3p0 and a DB driver, so if that is all that is 
> needed, configure it as you like.  If you are using ONS, I think we will 
> need to make the pool type configurable, and do some work to make sure it 
> is ONS compatible.  Penn is probably going to need this at some point, and 
> we use ONS for other things, so we will add this into Grouper at some point 
> if someone else doesn't do it sooner :)
> 
> Btw, we are just using hibernate with c3p0 in hibernate, maybe there is a 
> way to adjust the grouper.hibernate.properties to use fcf without changing 
> code (I wouldn't bet on it, but maybe) :)
> 
> Thanks,
> Chris
>