Checks for explicit locks are unnecessary for ContentCollections
Description
Activity
Neal Caidin February 13, 2014 at 10:29 AM
Closing this one based on Sakai release team discussion , February 13, 2014.
Aaron Zeckoski December 19, 2013 at 9:49 AM
This ticket seems like it might be dead... suggest we kill it unless it gets some activity before 2014
Aaron Zeckoski October 21, 2013 at 8:21 AM
Is this still relevant or has the code changed around since this ticket was created?
Jim Eng August 27, 2009 at 11:07 AM
Here are samples for the three queries:
select RESOURCE_UUID from CONTENT_RESOURCE where RESOURCE_ID=x'2F757365722F61333861393663612D393531392D343337302D623239392D3733343230323937646166352F'
update CONTENT_RESOURCE set RESOURCE_UUID = null where RESOURCE_UUID = x'36373961373031622D383930312D343431332D393966372D326461353934373330313832'
update CONTENT_RESOURCE set RESOURCE_UUID = x'36373961373031622D383930312D343431332D393966372D326461353934373330313832' where RESOURCE_ID = x'2F757365722F61333861393663612D393531392D343337302D623239392D3733343230323937646166352F'
All three of these queries are issued while handling a call to DbContentService.getUuid(id), which is called by CHS.checkExplicitLock(id).
Jim Eng August 27, 2009 at 10:59 AM
Assigning to Noah for comments about whether there is any reason not to eliminate the call to checkExplicitLock(id) for collections. Explicit locks are used primarily (or exclusively?) for OSP artifacts, I believe. So the question is whether eliminating this call for collections would create a problem for OSP.
Calling CHS.allowUpdateCollection(id) or CHS.allowUpdateResource(id) (to see whether the current user can update a content entity) results in a call to checkExplicitLock(id). Locks are created using the RESOURCE_UUID, so checkExplicitLock(id) checks whether the entity has a RESOURCE_UUID and tries to assign one if it doesn't. Since ContentCollection's do not have RESOURCE_UUID's, this results in three meaningless SQL queries each time checkExplicitLock(id) is called.