JBoss Cache lock UpgradeException when simultaneous requests with the same SSO create new sessions

When more than one request with the same SSO ID creates a session at the same time, some may fail with an org.jboss.cache.lock.UpgradeException.

The root cause is that TreeCacheSSOClusterManager.addSession/removeSession first get a read lock, then upgrade to a write lock.
In 5.x, addSession is ok, only removeSession has this issue.

The fix is to get a write lock up front, instead of starting with a read lock then upgrading.

For AS 4.x, since JBoss Cache 1.4.x doesn't have Option.setForceWriteLock, adding something like the following
before the cache.get should force a write lock:

cache.put ( fqn, "LOCK", null, LOCAL_OPTION );

[org.jboss.web.tomcat.service.sso.TreeCacheSSOClusterManager] caught exception adding session C4851CD53FB091272E78A9395C0C15F1 to SSO id 821E74E80D46822B77FB774E8AEF67D8
...
Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/SSO/821E74E80D46822B77FB774E8AEF67D8/sessions, caller=GlobalTransaction:<10.0.0.1:61628>:4, lock=read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
at org.jboss.cache.Node.acquire(Node.java:517)
...
Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /SSO/821E74E80D46822B77FB774E8AEF67D8/sessions (caller=GlobalTransaction:<10.0.0.1:61628>:4, lock info: read owners=[GlobalTransaction:<10.0.0.1:61628>:4, GlobalTransaction:<10.0.0.1:61628>:5] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
...
Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:106)
at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175)