4 Replies Latest reply on Dec 4, 2009 3:15 AM by 696067

    Locking

    696067
      I'm a bit unclear on how transactions in ModelOracleSem and GraphOracleSem work.

      1) Will a model.begin() block any other writers from making changes to (but not readers from reading) the model until model.commit() is called? (this is the behavior I am looking for...)

      2) What is the difference between model.commit() and graph.commitTransaction()?

      3) Do the model transactions and/or graph transactions use Oracle's ReadCommited/Serializeable/ReadOnly transaction level settings?
        • 1. Re: Locking
          alwu-Oracle
          Hi,

          No to 1). Why do you want to block all other writers? That will limit the concurrency. If your application really needs a serialization, you may want to look into dbms_lock or "select ... from <tab> for update nowait " on a dummy table.

          model.commit() will simply call commit on the underlying database connection. graph.commitTransaction does a bit more house keeping before the commit. We recommend you to use graph.commitTransaction.

          Model/graph transactions use commit/rollback on the underlying database connection. There is no logic to change the transaction level in Jena Adaptor code.

          A small quote from Tom Kyte (http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html)

          "READ COMMITTED is perhaps the most commonly used isolation level in database applications everywhere, and it's the default mode for Oracle Database. It's rare to see a different isolation level used in Oracle databases."

          Hope it helps,

          Zhe Wu
          1 person found this helpful
          • 2. Re: Locking
            696067
            Hum, well here's what I'm afraid of... Say that I have an In-Memory model and an DB Model each with one statement:

            In-Memory: Node1 rdf:type Node
            Database-Model: Node1 rdf:type Node

            And I want to bulk-add the following statements (to both the DB and In-Memory Models):

            Node1 sbe:contains Node2
            ...
            Node1 sbe:contains NodeN

            Only issue is, unless Node1 is the type Node (i.e the statement "Node1 rdf:type Node exists") my Middle-Tier's rules-system (it does some validity checking outside of the model) should not allow that the addition of Node1 sbe:contains Node1 ... NodeN. For performance reasons, the Middle-Tier uses the In-Memory model to run the rules. The trouble is, what if in-between the time I run the Middle-Tier's rules and the Bulk Update, some other Middle-Tier deletes the DB statement "Node1 rdf:type Node" and the Bulk Update is pushed. Then instead of getting this state in the DB:

            -----
            Node1 rdf:type Node
            Node1 sbe:contains Node2
            ...
            Node1 sbe:contains NodeN
            -----

            I get this one... which is invalid.

            -----
            Node1 sbe:contains Node2
            ...
            Node1 sbe:contains NodeN
            -----

            Now it seems to me that if I do a model.begin() before I start to run the Middle-Tier Rules, the Read Committed Isolation will assure that the statement "Node1 rdf:type Node" will still be there when I do the bulk update (or perhaps if it was deleted by another client from the DB it will be restored). Is this true?
            • 3. Re: Locking
              alwu-Oracle
              Hi,

              It really depends on the order of transaction executions. Without additional application-level locking, there is no guarantee that you can find/read the data you just insert and commit. Forget RDF/OWL for now, just consider a plain relational table, say you insert 10 rows and then commit. Does this guarantee you can find those 10 rows using a follow-up SQL query? Not really. Other sessions may have removed those 10 rows and committed before your query is executed.

              If you insert 10 rows and do not commit, then you can surely find those 10 rows in a follow-up query.

              When you say bulk add, do you mean that your application is going to invoke addInBulk API? If so, then commit is part of the underlying logic.

              From what you described, I think you may need application-level locking.

              Thanks,

              Zhe Wu
              • 4. Re: Locking
                696067
                Ok, makes sense. I guess in instances when I need transactions I can use model.add(Model) or model.add(Statement[]) to ensure a single transaction.

                Thanks,
                Alexi