Announce: Database Backed Storage Service
Wessel, Keith
kwessel at illinois.edu
Tue Oct 1 15:10:23 EDT 2013
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+Storage+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
More information about the users
mailing list