Persistent session StorageService, choosing and configuring
Cantor, Scott
cantor.2 at osu.edu
Fri Jan 27 18:25:41 EST 2017
On 1/27/17, 5:52 PM, "users on behalf of Rich Graves" <users-bounces at shibboleth.net on behalf of rgraves at carleton.edu> wrote:
> There are worse things than users needing to authenticate but still.
Personally, I would say that if your production environment is for a single node and you don't constantly restart it that I would be very hard pressed to see why it's worth introducing the drastically higher complexity of a separate storage layer just to avoid a few extra logins, particularly if the transitions are done late at night. Just my opinion.
To me the storage issue is about clustering. I couldn't be paid enough to add memcache or a database to my IdP if I didn't need it. Take it for what it's worth. I have no experience with any of the options but client-side.
> Anyway, if you don't convince me to use memcached, I'm confused about
> the MySQL config. I got this far by interpolating StorageConfiguration,and some tips I found at tuakiri.ac.nz. There's been
> a lot of chatter about the MySQL config; which is "latest" and most authoritative for 3.3?
There is nothing new in 3.3 that has anything to do with it as far as I'm aware. I thought the issues came down to having to provide all the right hibernate mapping files, none of which I could comment on, but what needs to happen is for people using it to update the documentation, and not just add comments that create a long chain of confusing advice. There have to be authoritative deployers to provide the details and they should go in our wiki, not scattered around.
> In attribute-resolver.xml, I have been doing this successfully. What's
> the JPAStorageService equivalent?
That's a non-pooled data source. You would have to be operating at really low scale to get away with that. But the Spring bean equivalent is just exactly that, same driver, same settings.
Normal use of a database involves pooling, which I do with the DBCP pooling library as the "driver" around the underlying data source. I'm sure others have their favorite pooling libraries.
> With this (in global.xml), Jetty fails early with
> ClassNotFoundException: com.zaxxer.hikari.HikariDataSource. Where is
> that supposed to be and why don't I need it for attribute resolution?
I have no idea what it is, but you're telling it to use a different JDBC driver which you don't have. The driver class you're using in the resolver certainly isn't that. Possibly it is another pooling library like DBCP, which would explain why it's a wrapper around the MySQL driver.
-- Scott
More information about the users
mailing list