it should not take ~100 mulgara queries to build an article

Agreed - 100 is excessive. I have a hunch that using Views (in 0.9) may help here, but I'd also like to know how come we have 100 currently.

in 0.8.2.1, it was ~60, which is still too many.

in 0.8.2.2, with serializable cache keys, it was ~120

note that this is fetchArticle.action, getRatings, getTrackbacks, etc. etc. there are at least 3, maybe 5 or more actions that get called with fetchArticle, all involve some interaction with mulgara and some don't cache at all

(In [5575]) Added an Interceptor concept for OTM Sessions. This is similar to the Interceptor support provided by Hibernate.

This is to help Ambra resolve a number of tickets related to caching. Please see #900,#901,#829,#845,#861 (and may be more)

As part of this update, please note that the Transaction API has the following additions: 'isActive', 'wasCommitted' and 'wasRolledBack'.

(In [5576]) Basic infrastructure support for transactional cache updates and cache invalidations and also support for a journal context aware second-level cache (similar to Hibernate).

Addresses #900,#901,#829,#845,#861.

CacheManager? provides a READ_COMMITTED isolation level. Only cache that is managed by this CacheManager? now is the journal context aware object-cache for OTM. No changes to existing caches or cache-invalidations yet.

Rich to test cache in multi-stack environment.

Assigning to Pradeep as we discussed in the conference call.

Our performance tests should tell us new data.

Pradeep, assigning this back to you. Can you please run a quick test and gather some stats with regards to:

• How many article specific (including annotations, ratings) etc. does it take to fetch a new article (i.e. nothing is in cache)
• How many queries still go back to the repository once an article has been retrieved at least once?

Replying to amit:

100 or so number is correct. (Depends on the article). But the good news is that for the fetchArticle itself it is not a lot. The rest are for fetchObjects. The fetchObjects seems to be issued in parallel by Firefox and is utilising the multiple-concurrent-read-transactions support in the new mulgara.

This is for the first time an article is accessed. Subsequent accesses are all completely from cache and so no queries.

Here is the break down for fetchArticle:

1. xacml state-check on the article-doi - 1 query
2. Article get - 2 queries (get + rdf:List/rdf:Bag query)
3. Representations - 2 queries (xml, pdf)
4. List annotations - 3 queries (xacml-revokes, xacml-permit-creator, list query)
5. Each annotation - 5 queries (xacml-state, xacml-revokes, xacml-permit-creator, xacml-grants, get)
6. Ratings summary - 3 queries (list of ratings-summary, get on RatingsSummary?, get on RatingsSummaryContent?)
7. List of track-backs - 1
8. Each track-back - 2 (Trackback, Body)

Here is the breakdown for fetchObjects:

1. ObjectInfo? - 2 queries (xacml-state, get)
2. Representation - 1 per each representation

Thanks. Moving it out and keeping it open to get some data later from production systems.