[Deploying Sakai] UTF8 checks in DbContentService are locking the same row in CONTENT_RESOURCE on multiple app servers

[Martin B. Smith]

Hello all,

I'm coming across a bit of an annoyance when starting up multiple Sakai 
2.7.x (1.1 kernel, I believe), and I'm seeing lock contention in our 
Oracle database in the CONTENT_RESOURCE table.

I'm wondering if anyone has come across an issue when they start 
multiple Tomcat instances pointed against the same Sakai database, where 
the DbContentService's init() method eventually calls DbContentService's 
testUTF8Transport(), and from there on out, it's basically a textbook 
example of lock contention (starting at line 3192 in 
https://source.sakaiproject.org/svn/kernel/trunk/kernel-impl/src/main/java/org/sakaiproject/content/impl/DbContentService.java).

In our case, multiple application servers are all trying to delete, 
insert, and then query, the same row with the same RESOURCE_ID (which is 
a primary key), just to test UTF-8 support. After that, I basically have 
to wait for the locks to time out.

Has anyone worked around this by using app server-unique strings for the 
RESOURCE_ID in that table? Or do you just be sure never to have two app 
servers start up at once?

Thanks in advance,
-- 
Martin B. Smith
smithmb at ufl.edu - (352) 273-1374
CNS/Open Systems Group
University of Florida

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5497 bytes
Desc: S/MIME Cryptographic Signature
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20101122/49df15f4/attachment.bin