StorageService API

[Marvin S. Addison]

> I guess you would see it as equivalent in that it's more work, but I would
> not expect your CAS code proper to be calling that API, just as the SAML
> artifact profile code doesn't do so. I would have a TicketCache or
> whatever name is appropriate that has exactly the API you suggest, and
> wraps the storage API.

Perfectly reasonable and what I'll likely do, though your expectation of 
writing wrapper code is contrary to my assumption of using 
StorageService directly.

> That's alarming, I can't think why any properly written code would ever
> deadlock unless the database driver was just broken. Oracle unfortunately
> throws dirty write errors because of its default locking (or lack
> thereof), but those aren't deadlocks.

I should note we saw deadlocks proper on Oracle, but with a frequency of 
a couple per month. On PostgreSQL, I got a daily deadlock report 
containing tens to hundreds of entries. Here's a thoughtful post on 
pgsql-general describing the situation in painful detail:

http://www.postgresql.org/message-id/4C1A65F4.6050408@vt.edu

> This is with the CAS ticket cache, or something else?

Yes, just reads and writes on the ticket registry. It's a mix of user 
(servlet container) threads and background cleanup threads. You can see 
from the post that some of the locking semantics arise from the database 
schema and could be alleviated by some schema tweaks, but the design is 
fairly common and the severity of problems arising from something so 
ordinary is indeed alarming.

> The basic APIs (CAS ticket cache included) would be
> self-cleaning and not generally build up much disk usage.

It's not solely total disk or tablespace size, but also size of 
individual LOB fields. In our case we're serializing a HashMap that 
grows linearly with the length of the CAS SSO session and in some cases 
it exceeded the limits of the BLOB type on MySQL. That puzzled a fair 
number of folks, though the fix was simple: use LONGBLOB.

> That probably needed to be explicit: I am *totally* trying to propose a
> single API (for the components that can use such an API), to the exclusion
> of just about any other consideration.

Ok, that's what I understood.

> so you're correct that there is no reason whatsoever given what's there
> now to have separate methods for short/long data.

I think that change alone will be a meaningful improvement.

> Secondly, I'll try and look at building some support for automating or
> simplifying some of the simple wrapping required to store objects that
> have a natural mapping of fields to keys, values, expirations and such.
> Maybe just stuff in a new interface that our own objects that want to be
> directly storable can implement.

I was thinking along those lines as well, but it's not entirely clear 
how to accomplish it all with a single or even multiple interfaces. An 
Expirable interface seems pretty natural for indicating a component with 
natural expiration, but something like KeyValue seems overly broad. 
Combining into a single expirable key-value type seems even more 
problematic. Honestly, I think metadata annotations on the fields is the 
most flexible and least invasive solution, but that has a higher runtime 
cost. Still, I tend to favor those sorts of solutions unless there's 
clear evidence of a performance problem.

M