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

Similar Messages

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

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.

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 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 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

You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels

Hi, I have a piece of code that works fine in SSMS as T-SQL. When I put the T-Sql inside a SP, I get the error :
You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels
The script starts is as follows (only select)
SET NOCOUNT ON
Set Transaction Isolation Level Read Committed
Set Deadlock_Priority Low
Select......
From MyTable WITH (NOLOCK)
GROUP BY .....
Order BY ....
works fine as I said in SSMS as T-SQL but the SP generates the following
Msg 650, Level 16, State 1, Procedure usp_TotalMessages, Line 15
You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels.
By the way, when it says line 15, from where we should start counting, is it from The USE DB statement which includes comments as well as Set ANSI....or should we start counting from the Alter PRocedure statement
Thanks in advance

Set Transaction Isolation Level Read Committed
Set Deadlock_Priority Low
Select......
From MyTable WITH (NOLOCK)
GROUP BY .....
Order BY ....
First you define transactionlevel = "Read Committed", then you use a query hint "NOLOCK" which is equivalent to "Read Uncommitted"; so what do you want now, committed or uncommitted, you have to decide.
Olaf Helper
[ Blog] [ Xing] [ MVP]

How to get a row level share lock

Is it possible to acquire a row-level share lock, which would do all of the following?
1. Prevent others from updating that row.
2. Allow others to read that row.
3. Allow others to update other rows in the same table.
I have the following scenario where two transactions need to lock eachother out:
Set-up:
Insert into TABLE_A(value_a) values ('ok');
Insert into TABLE_B(value_b) values ('ok');
Transaction A:
Select value_b from TABLE_B
If value_b = 'ok', update TABLE_A set value_a = 'not ok'
Transaction B:
Select value_a from TABLE_A
If value_a = 'ok', update TABLE_B set value_b = 'not ok'
If transaction A runs first then the end result is "not ok" only in TABLE_A.
If transaction B runs first then the end result is "not ok" only in TABLE_B.
If the two transactions run concurrently, it is possible to get "not ok" in both tables. This is what I would like to prevent.
One way to get what I want is to use "select for update":
Transaction A:
Select value_a from TABLE_A for update
Select value_b from TABLE_B for update
If value_b = 'ok', update TABLE_A set value_a = 'not ok'
Transaction B:
Select value_a from TABLE_A for update
Select value_b from TABLE_B for update
If value_b = 'ok', update TABLE_B set value_a = 'not ok'
This way both transactions won't perform their update unless they know that the result if their select will still be the same after they commit. However, by using "select for update" Transaction A has gained an exclusive lock on the TABLE_B row. If a Transaction C with the same contents as Transaction A happens concurrently, then the two will block eachother even though all they both want is to read data from the same table.
Another way is to use "lock table", however using that would block out not only writes to a specific row, but writes to all rows in the table. (In my example there is only one row, but obviously that's just a simplified example.)
I have looked at the "serializable" isolation level, but that doesn't seem to help because the queries and updates involve more than one table.
I know that "reads don't block writes" is a fundamental part of the Oracle design that makes Oracle what it is, but is there any way I can explicitly make it happen anyway? Or can anyone see some other solution to what I'm trying to achieve?

Let me give a more real-world example to show what I'm talking about.
Imagine a simple bug-reporting OLTP application. Each bug has 3 fields:
1. Description
2. Resolution
3. Status (open/closed)
The application also has some rules:
A. If the Status is "closed", Description and Resolution cannot be changed.
B. In order to change the Status to "closed", both a Description and Resolution must be specified.
Now as long as only one person at a time updates a bug, everything is fine. However, if one person switches the Status to "closed" while another concurrently blanks out the Resolution you end up with a closed bug that has no Resolution. This is why some locking is necessary.
If Description, Resolution, and Status are all stored in the same table row, then it makes sense for each transaction to simply select the whole row FOR UPDATE, and then UPDATE it after it ensures all the rules are passed. However, in my fictional bug-reporting application they are all stored in separate tables. Now, the transaction that is making the change to Resolution could lock the row in the Status table FOR UPDATE (as everyone so far has suggested). Transactions making a similar change to the Description should then also lock the row in the Status table FOR UPDATE for the same reason. The end result of this is that Description changes and Resolution changes lock eachother out (can't happen concurrently, are serialized) when they don't need to be. Description changes and Resolution changes don't affect eachother, but because they both need to (exclusively) lock the same row, they are serialized.
If there was a way to acquire a share lock on the row in the Status table, then Description and Resolution changes would use that and not affect eachother. Status changes would still acquire an exclusive lock on the row, and would be blocked by (and block any further) concurrent Description and Resolution changes. This would be ideal.

Can you set isolation levels of message-driven bean transactions?

The problem: I have 3 different message-driven beans which each get a different type of message, except for a field that is common to all. That field is used as the primary key of an entity object. The message-driven beans configured to use a container managed transaction. Each message-driven bean, in processing the message, first does a lookup by primary key to see if the object associated with the key exists, and if it does not, it requests the entity's home object to create it. After that, they do further processing. The problem is that sometimes all the beans simultaneously get a message, resulting in each bean checking for the entity object at about the same time, and if they fail to find it (because none of them has created it yet), each creates an object, all with the same primary key. This is not caught until the beans start to complete their onMessage method, which I believe results in the container committing the transaction. One of the transactions will be committed successfully, while the other two will fail, get rolled back, and then be retried with the same message. The second time through, the other beans will find the entity object (since it has been created and committed) and they will complete correctly. In the end, they right thing occurs, except that there is a troubling exception or 2 in the log telling about the constraint violation (with the primary key) and the rollback. If it was just me, that would be fine, but our customer does not like to see exceptions in the log; that indicates to him that something is wrong.
So, I am looking for someway to make sure that the actions of the message-driven beans are serialized. One suggestion from a colleague was to set the isolation level of the transactions being used by the container in processing the message-driven beans' onMessage method. However, the documentation does not mention any way to do this for a message-driven bean. Suggestions?
Is the use of a UserTransaction a better way to do this? If I acquire a UserTransaction within the onMessage method of a message-driven bean, can I set its isolation level? How would this work? When I get a UserTransaction, does each client get a different transaction, or do they all get the same one?

(1) The WebLogic JMS "unit-of-order" feature is a heavily adopted feature that was specifically designed to handle similar use cases - see the JMS developer guide for extensive documentation. In your use case, if "key" is used to define UOO, then there's no limit on the number of keys that can be processed concurrently, but messages for any particular key will be processed single-threaded in the order in which they were first submitted.
Note that if you're using distributed destinations, the UOO feature is still fully supported - but the developer and/or administrator needs to decide whether to configure the destination to use "hash" or "path service" based routing (the JMS UOO edoc outlines the trade-offs).
(2) Another alternative is to use a single MDB with max-beans-free-pool that processes all three types (as the other poster suggested). I think this assumes all MDBs run on the same JVM.
(3) Another alternative is to use multiple queues, with a single MDB on each Q. Where some sort of hash algorithm is used to determine which Q is for the key. This approach is a "hand-coded" variant of the approach in (1) with "hash" based routing enabled...
(4) If all MDBs actually do run in the same JVM, a third alternative is to use code the application to use a common lock to protect each key, eg, something like:
// assume MyLock is simply a class with a "reference counter"
// assume some global "staticHM" hash map that is all MDBs can access
onMessage() {
MyLock lock = null;
key= msg.getKey();
synchronized(staticHM) {
lock = staticHM.get();
if (lock = null) {
lock = new lock();
staticHM.put(key, new lock());
lock.incRefCount();
try {
synchronized(lock) {
// only one onMessage will be able to lock a particular key at a time
do your work;
} finally {
synchronized(staticHT) {
if (lock.defRefCount() == 0) staticHM.remove(lock);
if (lock = null) staticHM.put(key);
If multiple threads get a message with the same key, then only one thread at a time will work on the key.
Hope this helps,
Tom

Setting isolation level with JDriver for Oracle/XA

edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a transaction and that 'Transactions use the transaction isolation level set
on the connection or the default transaction isolation level for the database'.
Does this mean that you shouldn't try to set it programatically (fair enough)
or that you can't set it in the weblogic deployment descriptor either? Also anybody
got any idea what the default is likely to be if you are using an Oracle 9iR2
database? Is this determined by some database setting?

IJ wrote:
edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a transaction and that 'Transactions use the transaction isolation level set
on the connection or the default transaction isolation level for the database'.
Does this mean that you shouldn't try to set it programatically (fair enough)
or that you can't set it in the weblogic deployment descriptor either? Also anybody
got any idea what the default is likely to be if you are using an Oracle 9iR2
database? Is this determined by some database setting?The system should honor the setting defined in the deployment descriptor,
however, for oracle it may not be helpful to change it. Oracle provides two
isolation levels. The default is always READ_COMMITTED. The other
setting is SERIALIZABLE, but this hurts performance, and is also problematic
in the way oracle implements it. For instance, even if you set SERIALIZABLE,
oracle will not lock read data. It will allow other transactions to read and/or
alter data trhat another ongoing SERIALIZABLE transaction has read. The
only way to really lock read data in oracle is to issue oracle-specific SQL in
your select: "SELECT ..... FOR UPDATE".
All in all, you should collect a strong case for why you can't proceed with
READ_COMMITTED first. Then you should research oracle's recommendations
(and their problem record) with SERIALIZABLE.
Joe Weinstein at BEA

Issues with transaction isolation levels (BEA-631 exceptions)

My intended EJB application will have a session bean that uses two very similar entity beans that will be mapped to different databases; in my test version the entity beans use the same database.
The final application will need XA transactions with isolation=serializable (beans may be in Oracle, DB2, or MSSQL databases); high probability of concurrent potentially interfering transactions.
My test example works (Windows XP, WebLogic 8.1, Oracle 9.2) with both BEA's Oracle driver, and the Oracle driver but only when I set a transaction isolation on the session bean as the Oracle specific "transactionreadcommitedforupdate".
If I try using "transactionserializable", I get an exception like the following when my session-bean first tries to find an entity bean:
<2/09/2005 10:13:43 AM EST> <Warning> <Common> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1f13e99" being released to pool "BEAOraclePool". Printing out current pool contents.>
(similar response with both drivers).
Please could someone explain what is wrong and why setting isolation serializable causes problems. How
should I fix things?

Hi. What version of 8.1 is this?
If you can easily reproduce this
we may either have a fix, or will
want to debug this.
Joe
Neil Gray wrote:
The bit about "cleaning up vendor connections" was from the comment by Imeshev that was earlier in this thread.
The context:
Application does involve possibility of two concurrent transactions trying to change the same row of a datatable; as isolation level is repeatableread or serializable, this will result in some exceptions. Sometimes exceptions handled ok, sometimes they cause problems.
Particular case illustrated below is when working with DB2. As I understand it, the two concurrent EJBs both make read requests (presumably acquiring read locks) then make update requests - if they happen to share a row this will block. I don't know enough about DB2 to know what controls its detection of problems. In practice I see db2 typically sending back an error to one of requestors in less than 1 second, but sometimes several seconds may elapse before the error response gets sent (I have observ
ed actual net traffic).
If transaction gets timed out in WebLogic (I've curently got a generous 8 second timeout setting in JTA tab) then there are problems.
First of two exceptions shown here is for normal case where db2 returned an error and it was handled ok:
11111111111111111
####<30/09/2005 10:55:39 AM EST> <Error> <EJB> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-010026> <Exception occurred during commit of transaction Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-1D5B56A9177C58E3D95B(17477508),Status=Rolled back. [Reason=weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=10,XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=rolledback,assigned=examplesServer),xar=BEADB2,re-Registered = false),SCInfo[examples+examplesServer]=(state=rolledback),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.Bi
gDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@eed1b8]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+): weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.
     at weblogic.jdbc.db2.DB2ImplStatement.executeBatch(Unknown Source)
     at weblogic.jdbc.base.BaseStatement.commonExecute(Unknown Source)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]
     at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:673)
     at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion: sync=weblogic.ejb20.internal.TxManager$TxListener@eed1b8
Error writing from beforeCompletion - with nested exception:
[weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]]
     at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
.>
222222222222222
Second case is where timeout in WebLogic occurred (I think) which leads to something messing up the connection pool
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <BEA1-22BE56A9177C58E3D95B> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1551d57" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1551d57" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@f95d4a" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Error> <EJB> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-010026> <Exception occurred during commit of transaction Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=9,seconds left=9,XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=rolledback,assigned=examplesServer),xar=BEADB2,re-Registered = false),SCInfo[examples+examplesServer]=(state=rolledback),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4})
,local properties=({modifiedListeners=[]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+): weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)
     at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1614)
     at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1117)
     at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1881)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+) - with nested exception:
[weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)]
     at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:325)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
.>
Once start getting those things released to pool the application falls apart. Shortly afterwards it loses all connections to DB2 (and DB2 may be left with some locks on the table that have to be cleared).
It isn't DB2 specific, if needed I can supply similar data for MSSQL server (BEA or MS drivers)

Question Isolation level on performance

If I have a question for report, and this report is not really realtime necessary(for example, munites delay is fine). in order to improve performance for report, allow query to get dirty data even there is a transaction lock on on table. So if change isolation level from 3 to 1 or 0, any big performace gain?

Not sure what the functionality of the report is but you may also look at using the "readpast" query hint which allows skipping rows which on which incompatible locks are being held.
Dirty read should be carefully evaluated/explained with the users of report since sometimes they will approve dirty read for performance benefit but won't really understand the implication. Just from my book of experience.
warm regards,
sudhir

Isolation level in cftransaction

Hi all,
We have been using cftransaction on our transaction process page where we need to do multiple insert queries to save transaction data. If there is no error, we commit the transaction. Once in a while though, we get the error message "Transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction." We are on SQL Server 2005.
What I understand from that error message is that there are multiple transactions trying to access the same tables at the same time. Implicitly, one transaction has locked the tables while it is inserting data, and other transactions are not able to access them.
Now I don't fully understand cftransaction beyond its commit / rollback functionality. I never quite understood the isolationLevel attribute of cftransaction. I have read a number of descriptions, but the terms dirty read, phantom data, nonrepeatable reads are still confusing to me. What I do understand is that unless we specify isolationLevel = serializable in a transaction, it is not locking the tables it is accessing. In our use of cftransaction, we don't specify the isolationLevel attribute ( I believe the default is read committed .)
So here are my questions:
1. If we don't specify any isolation level, why are we getting deadlock transactions?
2. If we do want to lock the tables using isolationLevel = serializable, does a concurrent transaction trying to use the same tables automatically get deadlocked? Or is there a mechanism to specify timeout ala cflock timeout attribute?
I'd appreciate someone clearing up my understanding of cftransaction. Thanks!

I know this is an old post, but I have had the same questions recently and based on my recent findings, have attempted to answer your questions below for anyone in the future:
1. If we don't specify any isolation level, why are we getting deadlock transactions?
The reason this could be happening is because the cftransaction tag will use the default isolation level of your database. For SQL Server this is usually Read Committed. However, it is important to note that, "Choosing a transaction isolation level does not affect the locks acquired to protect data modifications. A transaction always gets an exclusive lock on any data it modifies, and holds that lock until the transaction completes, regardless of the isolation level set for that transaction. For read operations, transaction isolation levels primarily define the level of protection from the effects of modifications made by other transactions." This quote is taken directly from the MS SQL Server site. I understand this by stating that if you are doing a read, the isolation level determines the quality and/or quantity of the data returned from the read. If you are doing data modifications, the transaction will always get an exclusive lock on any data being modified. The cftransaction tag can control when it is committed based on its placement, but does not control the data modification isolation levels.
2. If we do want to lock the tables using isolationLevel = serializable, does a concurrent transaction trying to use the same tables automatically get deadlocked? Or is there a mechanism to specify timeout ala cflock timeout attribute?
The first question helps to answer this second one. The isolation level attribute (serializable or other) applies to the level of protection read operations will receive from other transactions' modifications. It does not effect on the locks aquired to protect data modifications. This is controlled by the database itself. The cflock tag only applies to CF meaning it ensures single thread access to that code (e.g. application, session or server variables), not to the database.
I hope this helps someone in the future and that I have not misstated anything. If anyone can provide better clarification please do so.

Isolation level in EJB

Hi people,
I set isolation level into ejb-j2ee-engine.xml adding entity bean methods in order to have a lock in the records table (Oracle). In the xml I have the follow for each method:
     <transaction-descriptor>
          <isolation-level>
               <method>
                    <ejb-name>DatabaseTabaccaiEjbBean</ejb-name>
                    <method-name>ejbFindByPrimaryKey</method-name>
                    <method-params>
                         <method-param>java.lang.Long</method-param>
                    </method-params>
               </method>
When I deploy the EAR containing the EJB project I have the follow error:
Caught exception during application deployment from SAP J2EE Engine's deploy service:java.rmi.RemoteException: Cannot deploy application sap.com/DatabaseTabaccaiEar.. Reason: Cannot find method ejbFindByPrimaryKey(java.lang.Long) declared in ejb-j2ee-engine.xml.; nested exception is:      com.sap.engine.services.ejb.exceptions.deployment.EJBXMLParserException: Cannot find method ejbFindByPrimaryKey(java.lang.Long) declared in ejb-j2ee-engine.xml. (message ID: com.sap.sdm.serverext.servertype.inqmy.extern.EngineApplOnlineDeployerImpl.performAction(DeploymentActionTypes).REMEXC)
Where is the problem?
Thanks,
Vito

For 5.1, look at:
          http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#107261
          7
          http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_reference.html#1061916
          "marshalli" <[email protected]> wrote in message
          news:3a59546d$[email protected]..
          >
          > How to set the isolation level(Container Manager or Bean Manager) in EJB.
          Thanks
          >
          >

Isolation Level vs. Locking

Similar Messages

Maybe you are looking for