Announce: Database Backed Storage Service

[Paul Hethmon]

Keith,

I can tell you how I handle it. I use the Tomcat container managed
connections, because I get better pool management from it. I then put my
hibernate.properties in the Tomcat lib directory. So all DB configuration
is done at the Tomcat level, not the webapp level. The
hibernate.properties essentially just becomes a pointer to the container
managed stuff. If I have data resolvers that use a RDMS, I use the syntax
to point them directly at the container managed connection.

Paul

On 10/1/13 3:10 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Paul and others,
>
>A couple questions related to implementing this and the database layer.
>
>First, if we plan to have our IDP use the same database instance for both
>session storage and persistent StoredIDs using the StoredID connector
>(for eduPersonTargetedID values), does a container-managed database
>connection make more sense? Seems like we're going to be adding extra
>traffic and load to our database if we configure the database connections
>for these in hibernate.properties and attribute-resolver.xml respectively
>instead of inside our context fragment for Tomcat. I have limited
>understanding of this, though, and want to make sure that's right. The
>only advantage I see to not using the container-managed connection is the
>ability to access storedIDs from the command-line with things like
>aacli.sh, and there's only limited value to that.
>
>Second question: if we don't use the container-managed connection and
>instead use hibernate.properties, do you have any suggestions of a good
>place on the classpath to put hibernate.properties? We're using Tomcat.
>Can it go in the IDP's war file lib dir? Since we use the same war file
>on our test and prod IDP clusters which use separate databases, I'd like
>to not put it inside a war file if I can help it. Is there a standard
>place under Tomcat or the IDP where this will get picked up without me
>having to modify the classpath set by Tomcat?
>
>Thanks for any help, I'm more of a novice in this area than I'd like to
>be.
>
>Keith
>
>
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Paul Hethmon
>Sent: Tuesday, August 27, 2013 9:30 AM
>To: Shibboleth Users
>Subject: Announce: Database Backed Storage Service
>
>I finally got my database backed storage service packaged up for public
>release:
>
>https://wiki.shibboleth.net/confluence/display/SHIB2/Database+Backed+Stora
>ge+Service
>
>That page hopefully gives all the information needed to get it running. A
>few key points:
>
>1. It uses Hibernate for the data access layer, but I have only connected
>it to MySQL.
>2. The build script is Ant based which means dependencies will be a pain.
>I do have a goal to switch it to Maven, but don't hold your breath.
>3. There is a binary distribution in the Subversion repository. Java 6.
>4. I run a lot of copies of the IdP in my job that are logically
>distinct. You will see that the storage service requires a constructor
>argument to let it know which bucket to place the sessions. What you use
>does not matter. Only sessions with the same key are considered to be in
>the same logical group.
>5. The code will hide ALL database failures. The idea was that a database
>failure would not prevent a user from logging in. It might require them
>to re-authenticate, but they will be able to login.
>
>Please let me know what I forgot in the documentation, either on this
>list or direct is fine.
>
>thanks,
>
>Paul
>
>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net