[ACE-1253] Some webscripts are declared "readwrite" but should be declared "readonly" if they do not update the repository. Created: 05-Sep-11  Updated: 08-Sep-16  Resolved: 08-Sep-16

Status: Closed
Project: Alfresco One Platform
Component/s: Web Scripts and Surf
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Philippe Dubois [X] (Inactive) Assignee: Closed Issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 days, 30 minutes
Original Estimate: 0 minutes

Attachments: Text File cache1.txt     Text File cache2.txt    
Issue Links:
is related to by ALF-11330 Incorrect friendly message while crea... Closed
is related to by ALF-10413 All blog GET webscripts should be mar... Closed
is related to by MNT-7359 Adding bulk fetching for the associat... Closed
Test In: Enterprise
ACT Numbers:


Epic Link: Platform Hygiene 5.1


Some wescripts are declared <transaction allow="readwrite"...> but should be declared <transaction allow="readonly" > if they do not update the repository.

Some wescripts are declared <transaction allow="readwrite"...> but should be declared <transaction allow="readonly" > if they do not update the repository. One of the bad side effect of that is a lower usage of the L2 cache.

How to reproduce :

Install an AOB 3.4.4 version
Activate the cache debugging, see http://wiki.alfresco.com/wiki/Repository_Cache_Configuration, I have set <property name="startDelayMinutes"><value>1</value></property> and <property name="repeatIntervalMinutes"><value>1</value></property>
Activate statistics for « ContentDataCache »
Then start, upload 20 documents in the first level of the document library in SHARE, pdf docs are OK.
Push the « refresh » button in the browser with an intervel of 15 secs 10 time.
Stop Alfresco, edit /apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/doclist.get.desc.xml and set <transaction allow="readonly" buffersize="0">required</transaction>

Observed result :
The hit factor for « ContentDataCache » is very low when you execute first time with « allow="readwrite" », see cache2.txt
If you switch to <transaction allow="readonly" buffersize="0"> the hit factor is much higher. See cache1.txt

Remark : I think that this behavior is logical, what is wrong IMO is that we have declared doclist.get.desc.xml « readwrite ». It works because thumbnails are done in the background, asynchronousely in another transaction.

I have extablished a list of candidates webscrips that could have the same fault and that should be check in order to increase cache usage:

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/repository/discussions/forum/forum-posts.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/repository/links/links.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/repository/links/link/link.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/repository/tagging/tagscope-tags.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/datalists/list.delete.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/datalists/lists.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/categorynode.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/treenode.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/location.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/doclist.get.desc.xml~

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/node.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary/images.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/wiki/page.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/wiki/pagelist.get.desc.xml

<root tomcat>apache-tomcat-6.0.32/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/wiki/version.get.desc.xml

Comment by Jan Pfitzner [ 07-Sep-11 ]

problem with doclist & CO is not the thumbnail generation. Problem is, that site containers are not created during site creation via SiteServiceImpl. Instead of documentLibrary container is created when the 1st user calls the doclist webscript:
org\alfresco\slingshot\documentlibrary\parse-args.lib.js line 300ff

Same with other site containers like wiki: wiki/pagelist.get.js & wiki/lib/wiki.lib.js

Comment by Mike Hatfield [ 07-Sep-11 ]

Hi Jan,

Yep - the historical reason is that no single component knows what the list of containers are or will be (incl. customisations and extensions). Additionally, it's possible to configure the various components to work with containers other than their default names. Again, there isn't any concept of a central container manager to handle this.

Comment by Jan Pfitzner [ 08-Sep-11 ]

I prefer to create containers during site creation, thus I implemented a custom SiteService & marked the relavant WebScripts as readonly & modified some JS files that original handle the lazy container creation. It's a basic project solution...I guess you'll need a more complex central "ContainerManager"

public class FmeSiteServiceImpl extends SiteServiceImpl {

  • Logger instance.
    private static final Logger LOGGER = Logger.getLogger(FmeSiteServiceImpl.class);

private Map<String, String> container;

public SiteInfo createSite(String sitePreset, String passedShortName, String title, String description,
SiteVisibility visibility) {

final SiteInfo site = super.createSite(sitePreset, passedShortName, title, description, visibility);

// Create containers
AuthenticationUtil.runAs(new AuthenticationUtil.RunAsWork<Void>() {
public Void doWork() throws Exception {
if (LOGGER.isDebugEnabled())

{ LOGGER.debug("creating container for site "+ site.getShortName()); }

Set<String> keySet = container.keySet();
for (String containerName : keySet) {
Map<QName, Serializable> containerProperties = new HashMap<QName, Serializable>(1, 1.0f);
containerProperties.put(ContentModel.PROP_TITLE, container.get(containerName));
if (LOGGER.isDebugEnabled())

{ LOGGER.debug("created container "+ containerName +" " + container.get(containerName)); }

createContainer(site.getShortName(), containerName, null, containerProperties);

return null;

}, AuthenticationUtil.getSystemUserName());
return site;


  • @param container Container to set
    public void setContainer(Map<String, String> container) { this.container = container; }


<bean id="siteService" class="de.fme.alfresco.repo.site.FmeSiteServiceImpl" init-method="init">
<property name="nodeService" ref="NodeService"/>
<property name="fileFolderService" ref="FileFolderService"/>
<property name="searchService" ref="SearchService"/>
<property name="namespaceService" ref="NamespaceService"/>
<property name="permissionService" ref="PermissionService"/>
<property name="authenticationContext" ref="authenticationContext"/>
<property name="personService" ref="PersonService"/>
<property name="activityService" ref="activityService"/>
<property name="taggingService" ref="TaggingService"/>
<property name="authorityService" ref="authorityService"/>
<property name="dictionaryService" ref="DictionaryService"/>
<property name="tenantAdminService" ref="tenantAdminService"/>
<property name="transactionHelper" ref="retryingTransactionHelper"/>
<property name="sitesXPath">
<property name="tenantService" ref="tenantService"/>
<property name="roleComparator" ref="siteRoleComparator" />
<property name="sysAdminParams" ref="sysAdminParams"/>
<property name="container">
<entry key="documentLibrary">
<value>Document Library</value>
<entry key="wiki">
<entry key="blog">
<entry key="datalists">
<value>Data List</value>
<entry key="discussions">

Comment by Gavin Cornwell [ 21-Sep-11 ]

A partial fix and a unit test (ReadOnlyTransactionInGetRestApiTest) to help test affected webscripts has been added in revision 30664.

This initial commit has fixed most of the identified webscripts but there are plenty more in the system, I've therefore added a WARN logging statement to help identify these at runtime. Look out for warnings in the console that follow the format:

2011-09-21 08:57:46,431 WARN [web.scripts.RepositoryContainer] [main] Webscript with URL '<url>' is a GET request but it's descriptor has declared a readwrite transaction is required

I'd suggest that separate issues are raised for these on an individual basis (or related group of webscripts).

Comment by Gavin Cornwell [ 21-Sep-11 ]

Removed the blog.get.desc.xml webscript from the list in the description as this will be covered by ALF-10413.

Comment by Derek Hulley [X] (Inactive) [ 11-Nov-11 ]

Caches have been modified to be less pessimistic. Reducing priority.

Comment by Brian Remmington [ 28-Mar-14 ]

Only those webscripts that currently are using readwrite transactions but only need readonly transactions should be changed as part of this issue. ACE-1252 can be used to deal with GETs that should be POSTs.

Comment by Derek Hulley [X] (Inactive) [ 08-Sep-16 ]

We will not be addressing this issue for the V0 APIs.
The new ReST APIs, the V1 APIs, have this functionality built in.

Generated at Mon Feb 18 19:14:15 GMT 2019 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.