Shibboleth Developers

[giacomo tenaglia <>]

Hi,
I'm testing ODBC store on Oracle with a load of 250 new sessions per
day, with two machines.

Everything seems to work fine (I'm having some "replay detected of
message ID", but I don't think they're critical), and this is very good
since we need to use Shibboleth authentication on a lot of load balanced
servers.

The only issue I'm having is an error on createRow(), happening roughly
once a day:

2008-02-13 15:27:48 ERROR XMLTooling.StorageService [127]: insert record 
failed (t=texts, c=_c933594478bf5fe0892e18bc9fbbf1a4, 
k=_e4dd3a82-7f85-46a7-8114-8bbcd95b1796)
2008-02-13 15:27:48 ERROR XMLTooling.StorageService [127]: ODBC Error: 
HY000:1:8177:[Oracle][ODBC][Ora]ORA-08177: can't serialize access for this 
transaction
2008-02-13 15:27:49 ERROR Shibboleth.SessionCache [127]: error storing 
assertion along with session: ODBC StorageService failed to insert record.

2008-02-13 21:26:41 ERROR XMLTooling.StorageService [58]: insert record 
failed (t=strings, c=MessageFlow, k=_14602097-d173-4e49-8ee1-0158ae5bc8e6)
2008-02-13 21:26:41 ERROR XMLTooling.StorageService [58]: ODBC Error: 
HY000:1:8177:[Oracle][ODBC][Ora]ORA-08177: can't serialize access for this 
transaction

The session is created anyway, and in the first example inserted
correctly in the ODBC store, so this is not a critical error. Anyway I'm
figuring out how to prevent this.

The problem is that Oracle throws this error to the ODBC driver, and the
application is supposed to retry the insertion. From Oracle SQL
Reference:

> ISOLATION LEVEL Clause
>
> Use the ISOLATION LEVEL clause to specify how transactions containing
> database modifications are handled.
>
>     - The SERIALIZABLE setting specifies serializable transaction
>       isolation mode as defined in the SQL92 standard. If a serializable
>       transaction contains data manipulation language (DML) that
>       attempts to update any resource that may have been updated in a
>       transaction uncommitted at the start of the serializable
>       transaction, then the DML statement fails.
>     - The READ COMMITTED setting is the default Oracle Database
>       transaction behavior. If the transaction contains DML that
>       requires row locks held by another transaction, then the DML
>       statement waits until the row locks are released.


I think that possible solutions are hardcoding the check into
createRow(), or changing the transaction isolation level for the storage
to READ_COMMITTED.

What do you think?

Ciao,
giacomo

-- 
giacomo tenaglia
Technical Student at CERN IT/DES-SIS
CNR Biblioteca d'Area di Bologna - http://biblio.bo.cnr.it
Phone +41 76 5003376 - 
sip: