Locks and Isolation Levels

Hello,
I'm new to the Oracle environment and have just started using PL/SQL on Oracle 8i. Where can I find info on how Oracle locks data and how transaction isolation levels are used? We've still not recvd our manuals so please any replies referring to manuals are not welcome!

You could move forward balance into its own table. That was, the SELECT will not lock on the original table. Most of the running balance schemes that I have seen take a snapshot as of a given date (say, statement printing date) and record both the timestamp and the amount. Next month, you simply get last month's vaule and timestamp and query on transactions after that timestamp.
- Saish

Similar Messages

CF10 Datasources and Isolation Level

I've been looking all over for a solution to this and have been unable to find one. In CF9 using jrun, we are able to set the default isolation level on a datasource so that any time it is used it defaults to dirty read in case a record is in a lock state it still returns the current data. However in CF10 with it using Tomcat, I cannot find anyway to even configure a datasource through Tomcat, or set the default isolation level on a datasource created in the CF10 administration panel. I know we could surround every single query with a <cftransaction> tag that sets the isolation level, but that is unrealistic as this is a very large web service with thousands of queries.
Can anyone help out with this? Thanks!

Hello
You should be able to see your inserted row in the same session
Session 1:_
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> SELECT * FROM demo;
        ID
        11
         1
         2
         3
         4
         5
         8
         9
        10
9 rows selected.
SQL>
SQL> INSERT INTO demo VALUES (11);
1 row created.
SQL>
SQL> SELECT *   FROM demo;
        ID
        11
         1
         2
         3
         4
         5
         8
         9
        10
        11
10 rows selected.
Session 2: Different session without committing the result from the above session_
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options
SQL> select * from demo;
        ID
        11
         1
         2
         3
         4
         5
         8
         9
        10
9 rows selected.Regards
Edited by: OrionNet on Jan 4, 2009 9:58 PM

Locking Mechanism/Isolation Level with Datastore (Pessimistic) Tr ansactions

What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?
Does the locking mechanism differ across database platforms? I had read
that only shared locks would be used on Microsoft SQL Server.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic transactions?
Thanks,
Sasha Haghani.

What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?Kodo sticks with the default isolation level of the JDBC driver in use
for transactions, as we've found that many drivers act up when assigned
a level manually.
To lock records during pessimistic transactions, SELECT FOR UPDATE is
used. For the most part, it gives good object-level locking, preventing
concurrent modification, even in applications that span multiple JVMs.
Does the locking mechanism differ across database platforms?The locking differs across databases only in that some DBs do not
support SELECT FOR UPDATE (in which case it is still possible to get
optimistic lock exceptions during pessimistic transactions), some DBs
use a different mechanism (SQLServer has a shared lock construct that is
just as good if not better), and some DBs place restrictions on its use
(Oracle and PostgreSQL cannot lock rows when a SELECT DISTINCT is used).
See the 'known bugs and limitations' appendix of the Kodo user guide for
a detailed listing of locking issues with each databse.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic
transactions?The lock column contains a counter to keep track of object versions. As
you suspect, it is used so that during optimistic transactions when no
locking is performed (or during pessimistic transactions on DBs or
queries that can't perform locking), the system is able to detect that
concurrent modification of an object has occurred and throw the proper
exception. This way data integrity is never lost, even without locking.
As an aside, you can always view the SQL generated by Kodo (and by
looking at it get a feel for how the various table columns are used,
etc) by setting a print writer in the
JDBCPersistenceManagerFactory.setLogWriter() method. Kodo will echo all
SQL to the given stream.
Happy coding.
-- Abe White
TechTrader

Jdbc mysql "select ... for update" and isolation level...

Dear, I am now writing an application, in which some worker threads will get a waiting job from database (mysql) and perform the processing.
To avoid workers getting the same job id, I have studied the topics about locks, isolation level, and something like "select ... for update".
The storage engine being used is innoDB. Actually the problem seems solved after using "select ... for update" to get the id, but I am just curious that do I also need to care about the isolation level. It is because when I do some experiments by setting the isolation level to serializable, but NOT using "SELECT ... FOR UPDATE" (just simple select), exception something like "deadlock found and try to restart transaction" occurs. Is there any relationship between these two things? Any comments are welcome!! Thanks!!!

ashipj wrote:
can u plz provide me with the code (connection string). Am new to Mysql.
And also the driver u are using.
Thank youDon't hijack other's topics. Kindly start your own. Don't do that before you read the [Sun JDBC tutorial|http://java.sun.com/docs/books/tutorial/jdbc/index.html] and the [MySQL JDBC documentation|http://dev.mysql.com/doc/refman/5.0/en/connector-j.html].

Oracle XA driver and isolation level

We have an Entity EJB that has isolation level specified in its
deployment descriptor and everything works fine if we use the non-XA
Oracle 9i driver.
However when we use the Oracle 9i Release 2 XA driver we get the
following exception:
java.sql.SQLException: Due to vendor limitations, setting transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
at
weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126)
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
at weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
at
weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.java:173)
at
weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164)
Note the 8.1.7 version that the container prints. The driver is
definitely 9i and not 8.1.7 and it's the very first thing in the classpath.
Is this a problem with the driver really or is it a WLS issue?
Thanks,
Dejan

Hi,
I removed the transaction isolation level setting from the deployment
descriptor and it works now as expected.
But in the meanwhile I also ran a test by using the driver directly
without Weblogic and I was able to successfully set the transaction
isolation level on the XA connections so I believe it's a Weblogic problem.
Dejan
Deyan D. Bektchiev wrote:
Yes,
We know about this but we just try to set it to the default one
(READ_COMMITED) which is probably redundant for Oracle but might not
be the default one for another DB vendor.
Here is the part of the deployment descriptor:
<transaction-isolation>
<isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
<method>
<ejb-name>Event</ejb-name>
<method-name>*</method-name>
</method>
</transaction-isolation>
Dejan
Slava Imeshev wrote:
Deyan,
I'm not 100% sure, but AFAIR oracle doesn't support all isolation
levels.
Which level do you set? Could you show us this part of the deployment
descriptor?
Slava
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
Thanks for the reply Sree,
Yes the 9i driver is the very first thing in the classpath as otherwise
we wouldn't even be able to connect to the 9i database with the 8.1.7
driver (we were getting lots of other exceptions when we were still
using the 8.1.7 driver).
I'll try removing the setting of the isolation level and I'll post the
result to the newsgroup.
Dejan
Sree Bodapati wrote:
hi Deyan,
java.sql.SQLException: Due to vendor limitations, setting
transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
should not have showed up with wrong version of oracle. If you can
verifiy
that the thin driver is the first thing in the classpath and you are
indeed
using the thin driver, This is a bug.
But in this case it looks like you need to remove the
TransactionIsolation
level from the EJB descriptor to get this to work. can you try that? I
will
forward this to one of our EJB engineers and see if we can get some
help
for
you.
sree
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
Sree,
We already did but the only answer we got was that the Oracle 9i
Release
2 driver was not at all supported by Weblogic 7.0 SP1.
But the certification page says that it is even certified...
So which one is true: The Oracle 9i Release 2 driver is not
supported or
is supported?
--dejan
Sree Bodapati wrote:
Please file a support case for this at [email protected]
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
We have an Entity EJB that has isolation level specified in its
deployment descriptor and everything works fine if we use the
non-XA
Oracle 9i driver.
However when we use the Oracle 9i Release 2 XA driver we get the
following exception:
java.sql.SQLException: Due to vendor limitations, setting
transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
at
weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
at
weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
at
weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.jav
a
>
173)
at
weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164
Note the 8.1.7 version that the container prints. The driver is
definitely 9i and not 8.1.7 and it's the very first thing in the
classpath.
Is this a problem with the driver really or is it a WLS issue?
Thanks,
Dejan

Multiple submits and Transaction setting and isolation level ????

From a Struts JSP,
I submit the form n times.
I have a session facade in place. The corresponding function has trnsaction attribute as "Required" and the isolation level as "serializable"
As a business rule the record cannot be inserted more than once.
But it is......
The Facade calls the Controller which in turn calls the VOA which calls DAO.
There is a find method which looks for that unique id if it exists it throws an Validation exception.
There are two scenes:
-----If I open two IE and submit the form it throws validation exception
-----If I click on submit more than once from the same IE it inserts as many records.
Can any one please put some light????
But the inserts is happening

Could you make the picture more clear, probably with some code snippets where the actual database handshake is taking place?
Also whether the business rule is a part of database constraints or is it done at the application level. From your description it seems that it is being done at the application level. Check if the find method check is getting executed each time, or is it being bypassed under certain conditions.

EJB Isolation levels in ejb-j2ee-engine.xml

Can anyone explain to me why I only seem to have the option of using the 'repeatable read' isolation level in Netweaver Developer Studio?
I'm new to SAP and Netweaver but as a seasoned J2EE developer I would have expected to find read committed, read uncommitted, serializable, as well as repeatable read.
Is there some SAP or Netweaver specific reason why I don't get to choose these options, or do I need to enable them by configuring properties somewhere?

Hi Steve,
The reason is that the J2EE Engine EJB Container supports Read Committed and Repeatable Read isolation levels and Read Committed is the default one. That's why you only have the option of specifying Repeatable Read.
For more information on locking and isolation levels please have a look at these documents:
http://help.sap.com/saphelp_nw04/helpdata/en/37/019b3e25f95f14e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/a1/d81db94a10bc4b83b3f60b0e3037e7/frameset.htm
Best regards,
Vladimir

Isolation level and optimist/pessimist locking

I am using baen managed transaction in which i have set the isolstion level according to my use...
Now whrer does the concept of Optimist/pessimist locking comes if i have set the isolation level(it should be always pessimist locking in this case??) ???

I am using baen managed transaction in which i have set the isolstion level according to my use...
Now whrer does the concept of Optimist/pessimist locking comes if i have set the isolation level(it should be always pessimist locking in this case??) ???

Locking issues with transaction-isolation levels

          I believe that my program is suffering from some sort of deadlock, and I was hoping
          for some feedback.
          I am helping to develop a trading system
          using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
          called LiveOrder that exposes several finder methods, most of which return java.util.Collections
          of LiveOrder EJBs.
          In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
          finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
          isn't really supported by Oracle), in an effort to eliminate phantom reads, which
          occur frequently if I do not use this isolation level. These finders all use transaction
          attribute 'Required'.
          It is my understanding that any transaction that calls any of these finders either
          will lock the database if no other transaction already owns the lock, or will
          wait until the lock is released if another transaction owns that lock. It also
          is my understanding that a transaction that owns a lock will always release any
          locks acquired upon expiration of that transaction (whether that be via commit
          or via rollback).
          However, this doesn't always appear the case: I have noticed occassionally that
          several clients "hang," as they wait for the lock that, for some reason, is not
          being released by its transaction. There do not appear to be any exceptions thrown
          by the system prior to the system hanging, and the Weblogic administration tool
          states that all transactions have been committed.
          If it helps, I have included the general algorithm for the main (i.e., most expensive)
          transaction:
          1. a client calls a stateless session EJB's processOrder method (which should
          implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
          2. the transaction invokes the LiveOrder finder method (this should lock the DB,
          so subsequent callers should block until the lock is released).
          3. the transaction invokes another LiveOrder finder method, returning a separate
          set of data.
          4. the transaction invokes a finder method from a separate entity EJB (called
          Security), which maps to a "read-only" table in the DB (default transaction-isolation
          level, Required attribute).
          5. the transaction invokes a finder method from yet another separate entity EJB
          (called SecurityMarketValues), which maps to some other table (not read-only)
          in the DB (again, default transaction-isolation level, Required attribute).
          6. the transaction writes to the SecurityMarketValues entity EJB.
          7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
          8. the transaction ends by exiting method processOrder (thus releasing the locks
          on the LiveOrder table in the DB).
          In the system, there also exist other transactions that occassionally call the
          LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
          order table (i.e., these transactions do not make calls to other DB tables, and
          close transactions almost immediately after starting them)
          Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
          ideas? I'm running out...


Jon,
          If there was an Oracle deadlock the DB would resolve it momentarily and
          will ultimately choose one transaction and throw an exception so it's
          not a DB deadlock.
          Take a thread dump at the very moment your system seems to be hanging
          and look at what the threads are doing.
          From your description it's not very unlikely that those threads of
          yours that take snapshots of the data will not disrupt the transactions
          so you may be surprised by the thread dumps that this is actually what
          happens -- those snapshot thread wait for some lock while holding locks
          needed by you other threads and it just slows down the system.
          Regards,
          Dejan
          Jon Gadzik wrote:
          >I believe that my program is suffering from some sort of deadlock, and I was hoping
          >for some feedback.
          >
          >I am helping to develop a trading system
          >using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
          >called LiveOrder that exposes several finder methods, most of which return java.util.Collections
          >of LiveOrder EJBs.
          >
          >In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
          >finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
          >isn't really supported by Oracle), in an effort to eliminate phantom reads, which
          >occur frequently if I do not use this isolation level. These finders all use transaction
          >attribute 'Required'.
          >
          >It is my understanding that any transaction that calls any of these finders either
          >will lock the database if no other transaction already owns the lock, or will
          >wait until the lock is released if another transaction owns that lock. It also
          >is my understanding that a transaction that owns a lock will always release any
          >locks acquired upon expiration of that transaction (whether that be via commit
          >or via rollback).
          >
          >However, this doesn't always appear the case: I have noticed occassionally that
          >several clients "hang," as they wait for the lock that, for some reason, is not
          >being released by its transaction. There do not appear to be any exceptions thrown
          >by the system prior to the system hanging, and the Weblogic administration tool
          >states that all transactions have been committed.
          >
          >If it helps, I have included the general algorithm for the main (i.e., most expensive)
          >transaction:
          >
          >1. a client calls a stateless session EJB's processOrder method (which should
          >implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
          >
          >2. the transaction invokes the LiveOrder finder method (this should lock the DB,
          >so subsequent callers should block until the lock is released).
          >
          >3. the transaction invokes another LiveOrder finder method, returning a separate
          >set of data.
          >
          >4. the transaction invokes a finder method from a separate entity EJB (called
          >Security), which maps to a "read-only" table in the DB (default transaction-isolation
          >level, Required attribute).
          >
          >5. the transaction invokes a finder method from yet another separate entity EJB
          >(called SecurityMarketValues), which maps to some other table (not read-only)
          >in the DB (again, default transaction-isolation level, Required attribute).
          >
          >6. the transaction writes to the SecurityMarketValues entity EJB.
          >
          >7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
          >
          >8. the transaction ends by exiting method processOrder (thus releasing the locks
          >on the LiveOrder table in the DB).
          >
          >
          >In the system, there also exist other transactions that occassionally call the
          >LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
          >order table (i.e., these transactions do not make calls to other DB tables, and
          >close transactions almost immediately after starting them)
          >
          >Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
          >ideas? I'm running out...
          >
          >
          >
          >

A string of question about Locking & Isolation Level

Hi All
It is highly appreciated if someone give offer answers to my below questions
1) There are two ways of locking mechanism: Pessimistic & Optimistic. In general, do all J2EE app server support all these two ways of locking ?
2) It seems to me that setting the isolation level to "serialization" should result in using pessmistic locking. If no so, please point out my misconcept and explain to me.
3) Are there any differences in the way of entity bean programming as different locking mechansim is adopted ?
4) With regard to optimistic locking, will the app server throw out exception as data contention is detected ? Is the way of handling dependent on app server? Or It is transparent to the developer of entity bean. Please give me an e.g of j2ee app server product how to handle this scenario.
5) To adopt the approach of "optimistic" locking, do l have to implement it on my own using bean managed entity bean.
6) It seems to me that optimistic locking can achieve better concurrency. If it is inherently supported by app server for its container managed entity bean (=> totally transparent to the developer of entity bean). Is it always the rule of thumb to config the server to use "optimistic" locking instead of "pessimistic" ?
Sorry for bombarding you guys with such long list of questions. l would be very thankful if someone can help me consolidate my concept on these topics.
Also, please send your reply to [email protected] as well
thanks & regards
Danny

Hi Danny,
I became interested about the optimistic locking recently. If the topic is not long forgotten then this may make some difference!
We have attacked the optimistic locking issue by introducing audit fields (MODIFY_BY_USER, MODIFY_DATE) in tables where concurrency needs to be implemented.
We are retrieving rows from the table (for display or update) through Stateless Session Bean using simple SQL SELECT. The audit fields are fetched along with the business data and are kept at the client. While any of the concurrent users tries to update the row the audit fields are sent to the application server along with the modified business data. The relevant Entity Bean checks for any difference in the timestamp of the audit field (MODIFY_DATE) value with the value in the database. If a mismatch is found it reports a business exception to the user. Otherwise, the row is updated with the lastest timestamp value in the audit field MODIFY_DATE.
This works fine when two update operations are not concurrent, i.e., two users submit their update requests in a time lag greater than the time taken by the transaction to complete. This alone could not prevent the dirty update on the database.
Hence, to prevent any concurrent update contending for the same row you need to set the following ejbgen tag in the Entity Bean:
concurrency-strategy = Exclusive<<<<<Note: We are using Weblogic 6.1 with SP4 and CMP (no BMP).
Please let me know if you have got a better solution to tackle this issue.
Chandra.

Isolation level 0 and java persistence frameworks

Hi,
i use www.castor.org as my persistence framework, castor have have its own lock engine and cache for entities, then i think to avoid some table lock in database to pass for JDBC connection the parameter isolation=0, as any update or write is made and controlled by castor in castor i dont have dirty data, anyone have experience with any other java persistence engine and used maxdb with lock engine managed by framework?
any insight about this are welcome.
best regards
Clóvis

> Hi,
>
> i use www.castor.org as my persistence framework, castor have have its own lock engine and cache for entities, then i think to avoid some table lock in database to pass for JDBC connection the parameter isolation=0, as any update or write is made and controlled by castor in castor i dont have dirty data, anyone have experience with any other java persistence engine and used maxdb with lock engine managed by framework?
>
Sure
The whole SAP NetWeaver stack runs with isolation level 0.
Works quite fine.
In fact there are certain features (like the count(*) optimization) that don't work consistently with isolation level 1 (read commited).
So you shouldn't get into trouble with that.
regards,
Lars

Isolation Level vs. Locking

Hello,
I am still wrestlling a bit with the issues involved in setting an isolation
level. I am using WL 5.1, Oracle, and CMP.
I do now understand the issues involved between Oracle's
SERIALIZABLE and READ-COMMITTED isolation levels, etc.
But I also note that weblogic uses a pessimistic locking
approach for serializing access to entity ejb's. Doesn't this
locking supercede anything but an isolation level of
SERIALIZABLE? What happens with an isolation level
of READ-COMMITTED, even though the access to an
entity within any transaction will be serialized anyway?
Are there issues related to persistence issues outside of
ejb's, such as using JMS persistent messages within the
same system (same connection pool, etc.).
Also, I note that the ejb 2.0 spec in weblogic will allow
a more optimistic locking model. In this case, how will
multiple commits behave, will they behave according
to the isolation level chosen (READ-COMMITTED
or SERIALIZABLE?).
It's all confusing. What is the point, in ejb 1.1, for allowing
the bean developer to specify an isolation level, if all
access to entities will be done with exclusive locks?
What happens with multiple result finder methods? Does
this place exclusive locks on each entity found, within
a transaction?
Should I spend more time worrying about locking
models or isolation levels.
Am I just going around in circles?
Jason
Jason Rosenberg
SquareTrade
(remove 'nospam' from my return address)

Well, for now, I am designing for Oracle. What do you mean
by hazy?
Kirk Wylie <[email protected]> wrote in message news:[email protected]...
Probably not something you can count on guaranteeing no blocking. The
database could very well block here, particularly if your'e using
anything other than Oracle on the back-end, and Oracle can be a bit,
ahem, hazy in its acceptance of its own semantics here.
Kirk Wylie
Jason Rosenberg wrote:
Well, if the database table is set up to use READ-COMMITTED,
then it shouldn't block on the database, correct?
Jason
Cameron Purdy <[email protected]> wrote in message news:[email protected]...
... which means it could block on the database, correct?
Cameron Purdy
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
A finder will never block on a container lock. For instance, imagine
that primary keys 3 and 4 are currently participating in a transaction
and are locked in server A. If a finder is called in server A which
returns these keys, the finder will run independently of the EJB server
locks. (Of course the database isolation will still apply.)
-- Rob
Jason Rosenberg wrote:
Ah, clustering saves the day!
I'm wondering though, since we don't have control over which
server in a cluster a given ejb may run on at any given time,
the concurrent behavior may be different to control. Some
times you can have concurrent access based on
READ-COMMITTED on the db level, and some times weblogic
will force a SERIALIZABLE behavior if 2 conflicting
ejb's get instantiated in the same container.
This is what I want. I would like complex finder methods
to be able to return a collection of primary keys over a
table, based on a READ-COMMITTED basis. This
needs to happen often, and shouldn't block (it's ok
if it misses out on uncommitted data in process, or
if it returns keys that may be in the process of being
deleted). But I don't ever want it to block because
another component has uncomitted changes in process.
Ideas? Wait for ejb2.0?
Jason
Rob Woollen <[email protected]> wrote in message
news:[email protected]...
It matters if you are in a cluster, or if othercomponents/applications
are accessing the same data.
It will also matter if your db does not have row-level locking.
-- Rob
Jason Rosenberg wrote:
I've excerpted below some of the text from the weblogic
documentation.
What this says to me is that, indeed, if an ejb entity is in anywayinvolved
in a transaction, all other transactions will be blocked frominstantiating
and using the bean instance until the transaction is over.
This is a de-facto SERIALIZABLE isolation level, is it not, with allthe
plusses and minuses. The plus is that data integrity is maintained,the
minus is that concurrent access is negatively effected.
What am I missing. Given this mechanism, what difference does it
make whether I use of a transaction isolation level ofREAD-COMMITTED
or SERIALIZABLE?
It looks like the story does change for ejb2.0.....
From the weblogic online documentation at:
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#108796
7
Locking Model for Entity EJBs
The EJB 1.1 container in WebLogic Server Version 5.1 uses apessimistic locking mechanism for entity EJB instances. As clients
enlist an EJB or EJB method in a transaction, WebLogic Server placesan exclusive lock on the EJB instance or method for the
duration of the transaction. Other clients requesting the same EJBor method block until the current transaction completes.
This method of locking provides reliable access to EJB data, andavoids unnecessary calls to ejbLoad() to refresh the EJB
instance's
persistent fields. However, in certain circumstances pessimistic
locking may not provide the best model for concurrent access to
the
EJB's data. Once a client has locked an EJB instance, other clients
are blocked from the EJB's data even if they intend only to
read
the persistent fields.
To improve concurrent access for entity EJB's, the WebLogic Server
EJB 2.0 container enables you to defer locking services to
the
underlying database. In most cases, the underlying data store can
provide finer granularity for locking EJB data, and improve
throughput for concurrent access to the bean's data. See EJB 2.0 forBEA WebLogic Server Overview for more information.
Cameron Purdy <[email protected]> wrote in message
news:[email protected]...
I believe the "locking" refers to an internal WL implementationthat
prevents multiple threads from accessing an EJB instance.
Cameron Purdy, LiveWater
"Jason Rosenberg" <[email protected]> wrote in message
news:[email protected]...
Hello,
I am still wrestlling a bit with the issues involved in setting
an
isolation
level. I am using WL 5.1, Oracle, and CMP.
I do now understand the issues involved between Oracle's
SERIALIZABLE and READ-COMMITTED isolation levels, etc.
But I also note that weblogic uses a pessimistic locking
approach for serializing access to entity ejb's. Doesn't this
locking supercede anything but an isolation level of
SERIALIZABLE? What happens with an isolation level
of READ-COMMITTED, even though the access to an
entity within any transaction will be serialized anyway?
Are there issues related to persistence issues outside of
ejb's, such as using JMS persistent messages within the
same system (same connection pool, etc.).
Also, I note that the ejb 2.0 spec in weblogic will allow
a more optimistic locking model. In this case, how will
multiple commits behave, will they behave according
to the isolation level chosen (READ-COMMITTED
or SERIALIZABLE?).
It's all confusing. What is the point, in ejb 1.1, for allowing
the bean developer to specify an isolation level, if all
access to entities will be done with exclusive locks?
What happens with multiple result finder methods? Does
this place exclusive locks on each entity found, within
a transaction?
Should I spend more time worrying about locking
models or isolation levels.
Am I just going around in circles?
Jason
Jason Rosenberg
SquareTrade
(remove 'nospam' from my return address)
Kirk Wylie | mailto:[email protected] | http://www.radik.com

SP2013 Bug Report: Health Reports - You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels.

There appears to be an error when trying to view Health Reports from Central Administration. A simple fix within a SharePoint Stored Procedure fixes the problem. I get the error message "You can only specify the READPAST lock in the READ COMMITTED or
REPEATABLE READ isolation levels." when just trying to click "View Health Reports" --> Go in CA.
I have found the same problem in some blog posts which leads me to believe this is a bug:
Problems Viewing Health Reports in SharePoint 2013
From the blog post "I managed to work around it by altering the
proc_GetSlowestPages stored procedure and commenting out the
WITH (READPAST) line. "
This also worked for me. It would be great if a fix could be released for this problem as it seems to cause other problems as well (site analytics freezes).

Hi Dennis
Hope you had found the hotfix and installed it.
For the benefit of others who visit this thread SharePoint Server 2013 Client Components SDK hotfix package addresses this issue.http://support.microsoft.com/kb/2849962
Regards
Sriram.V

Isolation level and performance impact?

Hi
I'm new to BDB JE and building some prototypes to evaluate it.
Given a simple usecase of storing the following key/value pair <String,List<Event>> mapping a user to his/her list of events, in the db. New events are added for the user, this happens (although fairly rarely) concurrently.
Using Serializable isolation will prevent any corruption to the list of events, since the events are effectively added serially to the user. I was wondering:
1. if there are any lesser levels of isolation that would still be adequate
2. using Serializable isolation, is there a performance impact on updating users non concurrently (ie there's no lock contention since for the majority of cases concurrent updates won't happen) vs the default isolation level?
3. building on 2. is there performance impact (other than obtaining and releasing locks) on using transactions with X isolation during updates of existing entries if there are no lock contention (ie, no concurrent updates) vs not using transactions at all?
Thanks!
Peter

Have you seen this section of the Getting Started Guide on isolation levels in JE? http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/isolation.html
Our default is Repeatable Read, and that could be sufficient for your application depending on your access patterns, and the semantic sense of the items in your list. I think you're saying that the data portion of a record is the list of events itself. With RepeatableRead, you'll always see only committed data, and retrieving that record from a JE database will always return a consistent view of a given list. See http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/isolation.html#serializable for an explanation of what additional guarantee you get with Serializable.
2. using Serializable isolation, is there a
performance impact on updating users non concurrently
(ie there's no lock contention since for the majority
of cases concurrent updates won't happen) vs the
default isolation level?Yes, there is an additional cost. When using Serializable isolation, additional locks are taken on adjacent data records. In addition to the cost of acquiring the lock (which would be low in a non-contention case), there may be additional I/O needed to fetch adjacent data records.
3. building on 2. is there performance impact (other
than obtaining and releasing locks) on using
transactions with X isolation during updates of
existing entries if there are no lock contention (ie,
no concurrent updates) vs not using transactions at
all? In (2) we compared the cost of Serializable to RepeatableRead. In (3), we're comparing the cost of non-transactional access to the default Repeatable Read transaction.
Non-transactional is always a bit cheaper, even if there is no lock contention. On top of the cost of acquiring the locks, non-transactional operations use less memory and disk space, and execute some transaction setup and teardown code. If there are concurrent operations, even in there is no contention on a given lock, there could be some stress on the lock table latches and transaction tables. That said, if your application is I/O bound, the cpu differences between non-txnal and txnal operations becomes more of a secondary factor. If you're I/O bound, the memory and disk space overhead does matter, because the cache is more efficiently used with non-txnal operations.
Regards,
Linda
>
Thanks!
Peter

Comparison and implications of Informix vs Oracle isolation levels and read consisten

We are migrating from Informix 7x to Oracle 9i. Does anyone have information regarding differences in Isolation Levels and read consistency methodologies of the 2 products and how this might influence application coding changes.
Thanks!
Dick

I would not touch Hibernate with a 10ft barge pole.
The best in Oracle, is standard pessimistic locking, using the default transaction isolation level.
However, this requires stateful client-server.
Web-based client-server is stateless. Which means optimistic locking is the only viable alternative. 3 choices with optimistic locking. Check each every row column for a row update/change. Add a version column to the row and compare before and after version numbers when updating. Checksum the row before and after and confirm the checksums are the same.
You need a keyboard, a bit of a brain, and some basic code to implement one of these as an optimistic locking interface for stateless client-server. Not Hibernate.

Locks and Isolation Levels

Similar Messages

Maybe you are looking for