Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Performance problems opening ontology in multi-user mode with ChAO

Ulf Licht Ulf.Licht at
Thu Oct 11 01:03:46 PDT 2012

Hello Tania,

the workaround to disable the Changes Tab, which needs to be done in the 
project on the server in order to persist for the clients, does make 
startup instantaneous. Seeing the changes for the selected instance in the 
collaboration panel is usually enough. Thank you for the advice! 
What is the Changes Tab needed for? How long does it take to open the 
Changes Tab with your ChAO containing 10 million rows ???

We did use the script to delete the subchanges but the number of rows in 
the ChAO table was only reduced from 195.000 to 165.000. In our case the 
factor 3-10 does not seem to hold true but we will continue to run the 
script from time to time.
We do not have a large number of annotations therefore disabling the 
precaching of annotation counts does not help us.
Our Protege version is 3.4.8 on client and server side. Our ontology (not 
ChAO) contains 15.528 frames, 14397 instances, 10 facets, 712 slots and 
409 classes according to Project-->Metrics.

Thank you,

Von:    Tania Tudorache <tudorache at>
An:     User support for Core Protege and the Protege-Frames editor 
<protege-discussion at>, 
Datum:  04.10.2012 19:40
Betreff:        Re: [protege-discussion] Performance problems opening 
ontology in multi-user mode with ChAO
Gesendet von:   protege-discussion-bounces at

Hi Ulf,

The times you are reporting are indeed bad, because your ChAO is still 
fairly small. We use ChAO in production since 2009 and keep all the 
changes. We have over 10 millions rows in the ChAO db. The problem in your 
case is the Changes tab (see below).

What happens is that some things in ChAO get cached at the initialization 
of a client (e.g. sorted changes if you have ChangesTab activated, and 
annotation counts), and these are the operations that take such a long 

Here are some things that we do occasionally:

1. Delete all subchanges (they increase the size of ChAO 3 to 10 times, 
depending on the type of changes you are making). You would still have the 
top level changes that make sense to the user. We do this when we have new 
releases of the software, or when we need to take the server down, because 
it is done with a mysql script and he server should not be running. The 
script is in our SVN, in case you would like to try it:

This script will create a new table (new_youroldtablename) that has all 
the subchanges removed. Usually, I drop the old ChAO table, and rename the 
new one with the old name. The indexes are however not renamed, so I use 
this script to rename the indexes:

(you would need to change the names in this script to match your 

2. If you have a large number of annotations, you can disable the 
precaching of annotation counts (the annotation count is shown in the 
class tree). You can add a line in your client


What version of Protege are you using? How large is your ontology?

In any case, a quick fix would be to disable the ChangesTab in the 
configuration of the clients. Then the GetSortedTopLevelChangesJob would 
not be called. You would still see the list of changes of the selected 
class in the collaboration panel in the Changes tab. If you need to make 
searches in the changes history, I suggest  using the Search tab in the 
collaboration panel.

Let me know how it goes!


On 10/04/2012 08:42 AM, Ulf Licht wrote:
Hello list,

we recently started to use the Change and Annotation Ontology (ChAO) with 
our Protege multi-user installation. It worked fine for a while but now we 

see serious performance degradation. The ChAO is persisted in an Oracle 
database and the table current contains about 195.000 entries after using 
it for a few weeks. Currently opening a project with an attached ChAO is 
impacted the most (up to 70 minutes). The client log file indicates that 
opening the ChAO for the project takes the longest time. We did some 
further analysis and found that a server job called 
"GetSortedTopLevelChangesJob", which is started by the Changes Tab of an 
Protege client, issues many individual prepared database statements, which 

take a lot of time to complete. We created additional indexes to mitigate 
the problem and brought the time for opening a project to about 20 
minutes, which is still not acceptable.

Did anyone experience similar performance problems while using the ChAO 
and has any idea how to improve it? Archiving the ChAO every few weeks is 
not an option since we would have to search for changes over many archived 

ChAOs. An archive interval of once a year would be acceptable. How do 
others handle archiving of ChAO information?

Best regards,

Esprit Europe GmbH
40882 Ratingen

P.O. Box:
Esprit Europe GmbH
40842 Ratingen

t +49 2102 123-0
f +49 2102 123-45100

Amtsgericht Düsseldorf,
HRB 28967, VAT-ID: DE 162905814
Geschäftsführer: W.T.C. van der Vis, Ernst-Peter Vogel, Jürgen Haas, 
Julia Merkel

Confidential Notice: The information in this document is confidential. It is intended only for the use of the named recipient. Internet communications are not secure and therefore our Company does not accept legal responsibility for the contents of this message. If you are not the intended recipient  please notify us immediately and then delete this document.

Please consider your environmental responsibility before printing this e-mail

More information about the protege-discussion mailing list