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] Help creating a server project

Barrett, Michael mike.barrett at med.nyu.edu
Fri Mar 2 14:27:24 PST 2012


Thanks again, Timothy.

I'm using protégé_3.4.7 on unix

The run_protege_server.sh script that comes with that (to start the server) includes:

TX="-Dtransaction.level=READ_COMMITTED"
...
OPTIONS="$MAX_MEMORY $HEADLESS $CODEBASE $HOSTNAME_PARAM ${TX} ${LOG4J_OPT}"
...
$JAVA_PATH/java -cp $CLASSPATH $TX $OPTIONS $MAINCLASS $SAVE_INTERVAL $METAPROJECT


The run_protege.sh script (to start the client) has no "-Dtransaction.level" parameter.

According to the MySQL documentation (http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html ),  "REPEATABLE_READ" is the default isolation level for InnoDB.

As I understand it that means that the server was using transaction level READ_COMMITTED (which is inconsistent with the STATEMENT bin_log format)  while the client (when not connecting through the server) was using transaction level REPEATABLE_READ.

Changing
TX="-Dtransaction.level=READ_COMMITTED"
to
TX="-Dtransaction.level=REPEATABLE_READ"
In run_protege_server.sh allowed everything to work the way I expected it to.

I wonder, though if this change has an effect on the reliability or consistency of the server?  I'm not a mysql guru, but I don't imagine that this parameter would have been put in the server startup script without a reason.

Thank you again for all your help.

 - Mike


-----Original Message-----

Date: Thu, 01 Mar 2012 11:20:21 -0800
From: Timothy Redmond <tredmond at stanford.edu>
To: User support for Core Protege and the Protege-Frames editor
	<protege-discussion at lists.stanford.edu>
Subject: Re: [protege-discussion] Help creating a server project
Message-ID: <4F4FCBF5.10703 at stanford.edu>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 02/28/2012 01:32 PM, Barrett, Michael wrote:
> Thank you very much for your reply, Timothy.  I will investigate making the changes suggested with our dba.

It occurred to me later that we could just treat the symptoms and ignore 
the cause.  If you set your transaction isolation level to read 
committed it is possible that your problem would go away.  You can do 
this by adding the jvm argument:

    -Dtransaction.level=READ_COMMITTED


>
> However, I don't see how this could be the problem.  I am able to edit the ontology if I use the unix client and open the project with the "open recent" button.  Using the same client, I have a problem if I try to edit after opening the project via "open other / server"

This is a bit hard to understand.  I just checked and both cases use 
REPEATABLE_READ transaction level by default.  I don't have your full 
stack trace but I am guessing that the exception occurs when you make a 
change to the ontology.

-Timothy

>
> I'm using the same database in both cases, changes I make when I open via the "open recent" method are visible when I open by the "open other / server" method.
>
>   - Mike
>
> ----------------------------------------------------------------------
>
> Date: Mon, 27 Feb 2012 14:33:26 -0800
> From: Timothy Redmond<tredmond at stanford.edu>
> To: protege-discussion at lists.stanford.edu
> Subject: Re: [protege-discussion] Help creating a server project
> 	stored in a database
> Message-ID:<4F4C04B6.8030803 at stanford.edu>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>
> Sorry for the late reply.
>
>> What am I doing wrong?
> I suspect that the answer is nothing.  Your exception:
>
>> Amongst the java output when I attempt to create a new class is the
>> statemet:
>>
>>          at java.awt.EventDispatchThread.run(Unknown Source)
>>
>> Caused by: java.sql.SQLException: Binary logging not possible.
>> Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for
>> binlog mode 'STATEMENT'
>>
> is a database error that I have never seen before.  It is not clear how
> it can be connected to a misconfiguration of Protege.  It could be a
> Protege bug but I am guessing it is connected to the database and its
> configuration.
>
> I did a search on google and found some immediate hits.  One was a mysql
> bug [1] but this message [2] was also interesting indicating a
> configuration of my.cnf.
>
> -Timothy
>
>
>
> [1] http://bugs.mysql.com/bug.php?id=40360
> [2] http://help.hannonhill.com/discussions/installation/56-database-error-on-upgrade-to-673
>
>
>
> **************************************************
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-discussion/attachments/20120301/ad1f8d74/attachment-0001.html>

------------------------------

_______________________________________________
protege-discussion mailing list
protege-discussion at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/protege-discussion


End of protege-discussion Digest, Vol 68, Issue 1
*************************************************


More information about the protege-discussion mailing list