Performance of "READ_ONLY" transactions

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

davidraines

In Alfresco, do "READ_ONLY" transactions have better performance than "READ_WRITE" transactions?

Does Afresco use any faster caching behavior when processing READ_ONLY transactions?

We are looking to improve the performance of our application, and we've noticed that a decent percentage of our WebScripts only read data, and never write it.  Notionally, they could be specified as "READ_ONLY" transactions.

Is that going to be faster?  When I read about transaction management in other systems (Java, JDBC, Hibernate, different databases) the answer is "Its complicated."  In some systems, a "read only" transaction is designed to improve the "correctness" of read operations, not to make them run faster.

I've read some of the Alfresco source code.  I can see that READ_ONLY transactions enforce that you can't do a write operation.  But I don't see anything obvious that they'll be faster... I know that Alfresco has an "optimistic locking" model, so its not as if a "READ_WRITE" actually blocks unless a WRITE occurs.

We run our Alfresco on Oracle databases, if that makes a difference.

Has anyone investigated this?

afaust

There is no specific difference as to caching for read-only transactions. But Alfresco will save on the overhead of updating the alf_transaction table with an additional transaction that needs to be tracked for changes by SOLR, so alone from that perspective Alfresco will be a tiny bit faster.

I cannot say that I have ever observed a noticably better performance just by using read-only transactions, but measurements of this effect would be highly selective to specific constellations of types of concurrent loads (read-only alone, scaling to X threads + read-only in parallel to writes, scaling to X/Y threads), dependent on the kinds of operations performed in those transactions and a lot of infrastructure factors.

Of course transaction isolation should be as restrictive as possible, but usally they will be solely dependant on the HTTP verb of the ReST API call, e.g. GET are always read-only, PUT/POST/DELETE are always read-write.

Instead of looking at transaction isolation for improvements, I would advise to look at the JVM heap usage, garbage collection metrics and potentially the cache sizing/utilisation. The latter has been shown to bring anywhere up to 200% improvements even on systems with a extremely well tuned DB (comparing worst-case "load from DB" vs. best-case "load only from cache").