Isolation Level for Transaction
Hi
Under the Advanced Mode in JDBC Adapter, there is an option " Isolation Level For Transaction ". I see two alternatives there, " Serializable " and " Repeatable Load ". Which one should we select and when do we select it ?
Radhika
Hi Radhika,
Check below documentation..
http://help.sap.com/saphelp_nw70/helpdata/en/22/b4d13b633f7748b4d34f3191529946/frameset.htm
Regards,
Swetha.
Similar Messages
-
Setting transaction isolation level for jDriver 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?Ian,
The default for Oracle (any version) is ReadCommitted. The only other
isolation level Oracle supports is Serializable but it's implemented in
such a way that you will be allowed to continue until commit time and
only then you might get an exception stating the the access for that
transaction could not be serialized.
I don't know for the jDriver but if you use the Oracle Thin XA driver
even if you set the isolation level in your descriptor you will get an
exception from Weblogic. It is a Weblogic bug and you can contact
[email protected] to get a patch.
Regards,
Dejan
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? -
How to set transaction isolation level for a method in a Local Interface
By reference at:
http://e-docs.bea.com/wls/docs61/ejb/reference.html#1071267,
the value for method-intf can only be "Remote" or "Home".
My question is--
How to set transaction isolation level for a method inside a Local Interface or
Local_Home Interface?
Thanks.
Xing
I'd try 6.1SP2. I'm pretty sure this works now.
-- Rob
Xing wrote:
> I tried "Local", but got an error when deploying the EJB jar, saying that only
> "Remote" or "Home" is allowed.
>
> Any idea?
>
> Xing
>
> Rob Woollen <[email protected]> wrote:
> >
> >
> >Use LocalHome or Local.
> >
> >-- Rob
> >
> >Xing wrote:
> >
> >> By reference at:
> >> http://e-docs.bea.com/wls/docs61/ejb/reference.html#1071267,
> >> the value for method-intf can only be "Remote" or "Home".
> >>
> >> My question is--
> >>
> >> How to set transaction isolation level for a method inside a Local
> >Interface or
> >> Local_Home Interface?
> >>
> >> Thanks.
> >>
> >> Xing
> >
> >--
> >
> >----------------------------------------------------------------------
> >
> >AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
> >
> >by Michael Girdley, Rob Woollen, and Sandra Emerson
> >
> >http://learnWebLogic.com
> >
> >
> >
> >
> ><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> ><html>
> >Use LocalHome or Local.
> ><p>-- Rob
> ><p>Xing wrote:
> ><blockquote TYPE=CITE>By reference at:
> ><br>http://e-docs.bea.com/wls/docs61/ejb/reference.html#1071267,
> ><br>the value for method-intf can only be "Remote" or "Home".
> ><p>My question is--
> ><p>How to set transaction isolation level for a method inside a Local
> >Interface
> >or
> ><br>Local_Home Interface?
> ><p>Thanks.
> ><p>Xing</blockquote>
> >
> ><pre>--
> >
> >----------------------------------------------------------------------
> >
> >AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
> >
> >by Michael Girdley, Rob Woollen, and Sandra Emerson
> >
> >http://learnWebLogic.com</pre>
> > </html>
> >
> >
AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnWebLogic.com
[att1.html]
-
Transaction Isolation Level for EJB methods
L.S.
I just found out the in OC4J one can not set the transaction isolation level on ejb methods. Moreover one needs to revert to bean managed transaction (manual coding of the ALL transaction logic) to set the isolation level.
On entity beans one can only set the isolation level for the whole bean (not on individual methods), and in session beans there is no way at all to set the isolation level.
This is on shear contract to all other application servers I used before (there one can declaratively set the isolation level for a ejb method, both in session and in entitybean deployment descriptors)
Is it foreseen in a future release to include such a valuable feature will be provided by oc4j?
Note that I was VERY surprised that OC4J could not handle this (I checked the j2ee spec, but admittedly the spec is a little vague about this support and makes it vendor dependent. the j2ee spec does not mandate this, except for CMP entity beans, but includes some suggestions on this ability. But most other application servers implemented the ability)
Regadrs,
ErikHello Erik --
I think we met in Perth recently?
Anyway, your information is correct.
We can set the transaction isolation level for each entity bean, at the bean level. We don't have for the specification of method level isolation settings -- I'd be interested to hear how you would like/do use this. What behaviour do you expect to see when a transaction is started that spans multiple methods on a bean with different declared isolation levels.
For session beans, we do not currently have the ability to declaratively specify the isolation level to use for the bean. I know this is not in the forthcoming 904 release, and will to check what is beyond that.
As you point out, this can be done programatically using the Connection.setIsolationLevel() method on any connections you are using from within the session bean.
I'd would like to log an enhancement request for you for this functionality. Can you send me an email at [email protected] and we'll take it offline.
-steve- -
Setting db isolation level on transaction without EJB
I'm using UserTransaction in the servlet container, to control XA transactions.
We're not using EJB. How do I set the database isolation level? I'm tempted
to use java.sql.Connection.setTransactionIsolation(). However, the Sun Javadoc
for that method says you can't call that after the transaction has started (which
makes sense). Right now, we're starting the transaction, getting a connection,
closing the connection, and committing the transaction. I guess that order won't
work if I want to set the isolation level. Or am I mixing apples and oranges
here? If I use UserTransaction, is it even appropriate to try to set the isolation
level on the connection?
All I really want to do is change the default isolation level. We do not need
different isolation levels for different use cases. (Not yet, anyway.) We might
have transactions against two different database instances or other resource managers.
That's why I want to use UserTransaction and XA transactions.
Thanks!
Steve Molitor
[email protected]
Only committed transactions are replicated to the subscriber. But it is possible for the report to see dirty data if running in READ UNCOMMITTED or NOLOCK. You should run your reports in READ COMMITTED or SNAPSHOT isolation , and your replication
subscriber should be configured with READ COMMITTED SNAPSHOT ISLOATION eg
alter database MySubscriber set allow_snapshot_isolation on;
alter database MySubscriber set read_committed_snapshot on;
as recommended here
Enhance General Replication Performance.
David
David http://blogs.msdn.com/b/dbrowne/ -
How to define TX_SERIALIZABLE isolation level for a CMP EJB
Hi JDev Team,
I have created a portable Primary Key Generator realized as a CMP Entity Bean which
has a method getNEXTID().
This method returns a PK from a table
and increments it by one.
My question is:
How can I set the transaction isolation level of getNEXTID() to TX_SERIALIZABLE in order to avoid phantom and dirty read problems?
Best Regards,
Stoyan K.Assuming you are using the bc4j cmp implementation, the default for isolation level is TX_READ_COMMITTED so I don't think you run the risk of phantom or dirty read.
Unfortnately as of now this property cannot be specified declaratively.
It looks like you want to run the getNEXTID() with the RequiredNew transaction attribute.
null -
Changing Isolation Level Mid-Transaction
Hi,
I have a SS bean which, within a single container managed transaction, makes numerous
database accesses. Under high load, we start having serious contention issues
on our MS SQL server database. In order to reduce these issues, I would like
to reduce my isolation requirements in some of the steps of the transaction.
To my knowledge, there are two ways to achieve this: a) specify isolation at the
connection level, or b) use locking hints such as NOLOCK or ROWLOCK in the SQL
statements. My questions are:
1) If all db access is done within a single tx, can the isolation level be changed
back and forth?
2) Is it best to set the isolation level at the JDBC level or to use the MS SQL
locking hints?
Is there any other solution I'm missing?
Thanks,
SebastienGalen Boyer wrote:
On Sun, 28 Mar 2004, [email protected] wrote:
Galen Boyer wrote:
On Wed, 24 Mar 2004, [email protected] wrote:
Oracle's serializable isolation level doesn't offer what most
customers I've seen expect it to offer. They typically expect
that a serializable transaction will block any read-data from
being altered during the transaction, and oracle doesn't do
that.I haven't implemented WEB systems that employ anything but
the default concurrency control, because a web transaction is
usually very long running and therefore holding a connection
open during its life is unscalable. But, your statement did
make me curious. I tried a quick test case. IN ONE SQLPLUS
SESSION: SQL> alter session set isolation_level =
serializable; SQL> select * from t1; ID FL ---------- -- 1 AA
2 BB 3 CC NOW, IN ANOTHER SQLPLUS SESSION: SQL> update t1 set
fld = 'YY' where id = 1; 1 row updated. SQL> commit; Commit
complete. Now, back to the previous session. SQL> select *
from t1; ID FL ---------- -- 1 AA 2 BB 3 CC So, your
statement is incorrect.Hi, and thank you for the diligence to explore. No, actually
you proved my point. If you did that with SQLServer or Sybase,
your second session's update would have blocked until you
committed your first session's transaction. Yes, but this doesn't have anything to do with serializable.
This is the weak behaviour of those systems that say writers can
block readers.Weak or strong, depending on the customer point of view. It does guarantee
that the locking tx can continue, and read the real data, and eventually change
it, if necessary without fear of blockage by another tx etc.
In your example, you were able to change and commit the real
data out from under the first, serializable transaction. The
reason why your first transaction is still able to 'see the old
value' after the second tx committed, is not because it's
really the truth (else why did oracle allow you to commit the
other session?). What you're seeing in the first transaction's
repeat read is an obsolete copy of the data that the DBMS
made when you first read it. Yes, this is true.
Oracle copied that data at that time into the per-table,
statically defined space that Tom spoke about. Until you commit
that first transaction, some other session could drop the whole
table and you'd never know it.This is incorrect.Thanks. Point taken. It is true that you could have done a complete delete
of all rows in the table though..., correct?
That's the fast-and-loose way oracle implements
repeatable-read! My point is that almost everyone trying to
serialize transactions wants the real data not to
change. Okay, then you have to lock whatever you read, completely.
SELECT FOR UPDATE will do this for your customers, but
serializable won't. Is this the standard definition of
serializable of just customer expectation of it? AFAIU,
serializable protects you from overriding already committed
data.The definition of serializable is loose enough to allow
oracle's implementation, but non-changing relevant data is
a typically understood hope for serializable. Serializable
transactions typically involve reading and writing *only
already committed data*. Only DIRTY_READ allows any access to
pre-committed data. The point is that people assume that a
serializable transaction will not have any of it's data re
committed, ie: altered by some other tx, during the serializable
tx.
Oracle's rationale for allowing your example is the semantic
arguement that in spite of the fact that your first transaction
started first, and could continue indefinitely assuming it was
still reading AA, BB, CC from that table, because even though
the second transaction started later, the two transactions *so
far*, could have been serialized. I believe they rationalize it by saying that the state of the
data at the time the transaction started is the state throughout
the transaction.Yes, but the customer assumes that the data is the data. The customer
typically has no interest in a copy of the data staying the same
throughout the transaction.
Ie: If the second tx had started after your first had
committed, everything would have been the same. This is true!
However, depending on what your first tx goes on to do,
depending on what assumptions it makes about the supposedly
still current contents of that table, it may ether be wrong, or
eventually do something that makes the two transactions
inconsistent so they couldn't have been serialized. It is only
at this later point that the first long-running transaction
will be told "Oooops. This tx could not be serialized. Please
start all over again". Other DBMSes will completely prevent
that from happening. Their value is that when you say 'commit',
there is almost no possibility of the commit failing. But this isn't the argument against Oracle. The unable to
serialize doesn't happen at commit, it happens at write of
already changed data. You don't have to wait until issuing
commit, you just have to wait until you update the row already
changed. But, yes, that can be longer than you might wish it to
be. True. Unfortunately the typical application writer logic may
do stuff which never changes the read data directly, but makes
changes that are implicitly valid only when the read data is
as it was read. Sometimes the logic is conditional so it may never
write anything, but may depend on that read data staying the same.
The issue is that some logic wants truely serialized transactions,
which block each other on entry to the transaction, and with
lots of DBMSes, the serializable isolation level allows the
serialization to start with a read. Oracle provides "FOR UPDATE"
which can supply this. It is just that most people don't know
they need it.
With Oracle and serializable, 'you pay your money and take your
chances'. You don't lose your money, but you may lose a lot of
time because of the deferred checking of serializable
guarantees.
Other than that, the clunky way that oracle saves temporary
transaction-bookkeeping data in statically- defined per-table
space causes odd problems we have to explain, such as when a
complicated query requires more of this memory than has been
alloted to the table(s) the DBMS will throw an exception
saying it can't serialize the transaction. This can occur even
if there is only one user logged into the DBMS.This one I thought was probably solved by database settings,
so I did a quick search, and Tom Kyte was the first link I
clicked and he seems to have dealt with this issue before.
http://tinyurl.com/3xcb7 HE WRITES: serializable will give you
repeatable read. Make sure you test lots with this, playing
with the initrans on the objects to avoid the "cannot
serialize access" errors you will get otherwise (in other
databases, you will get "deadlocks", in Oracle "cannot
serialize access") I would bet working with some DBAs, you
could have gotten past the issues your client was having as
you described above.Oh, yes, the workaround every time this occurs with another
customer is to have them bump up the amount of that
statically-defined memory. Yes, this is what I'm saying.
This could be avoided if oracle implemented a dynamically
self-adjusting DBMS-wide pool of short-term memory, or used
more complex actual transaction logging. ? I think you are discounting just how complex their logging
is. Well, it's not the logging that is too complicated, but rather
too simple. The logging is just an alternative source of memory
to use for intra-transaction bookkeeping. I'm just criticising
the too-simpleminded fixed-per-table scratch memory for stale-
read-data-fake-repeatable-read stuff. Clearly they could grow and
release memory as needed for this.
This issue is more just a weakness in oracle, rather than a
deception, except that the error message becomes
laughable/puzzling that the DBMS "cannot serialize a
transaction" when there are no other transactions going on.Okay, the error message isn't all that great for this situation.
I'm sure there are all sorts of cases where other DBMS's have
laughable error messages. Have you submitted a TAR?Yes. Long ago! No one was interested in splitting the current
message into two alternative messages:
"This transaction has just become unserializable because
of data changes we allowed some other transaction to do"
or
"We ran out of a fixed amount of scratch memory we associated
with table XYZ during your transaction. There were no other
related transactions (or maybe even users of the DBMS) at this
time, so all you need to do to succeed in future is to have
your DBA reconfigure this scratch memory to accomodate as much
as we may need for this or any future transaction."
I am definitely not an Oracle expert. If you can describe for
me any application design that would benefit from Oracle's
implementation of serializable isolation level, I'd be
grateful. There may well be such.As I've said, I've been doing web apps for awhile now, and
I'm not sure these lend themselves to that isolation level.
Most web "transactions" involve client think-time which would
mean holding a database connection, which would be the death
of a web app.Oh absolutely. No transaction, even at default isolation,
should involve human time if you want a generically scaleable
system. But even with a to-think-time transaction, there is
definitely cases where read-data are required to stay as-is for
the duration. Typically DBMSes ensure this during
repeatable-read and serializable isolation levels. For those
demanding in-the-know customers, oracle provided the select
"FOR UPDATE" workaround.Yep. I concur here. I just think you are singing the praises of
other DBMS's, because of the way they implement serializable,
when their implementations are really based on something that the
Oracle corp believes is a fundamental weakness in their
architecture, "Writers block readers". In Oracle, this never
happens, and is probably one of the biggest reasons it is as
world-class as it is, but then its behaviour on serializable
makes you resort to SELECT FOR UPDATE. For me, the trade-off is
easily accepted.Well, yes and no. Other DBMSes certainly have their share of faults.
I am not critical only of oracle. If one starts with Oracle, and
works from the start with their performance arcthitecture, you can
certainly do well. I am only commenting on the common assumptions
of migrators to oracle from many other DBMSes, who typically share
assumptions of transactional integrity of read-data, and are surprised.
If you know Oracle, you can (mostly) do everything, and well. It is
not fundamentally worse, just different than most others. I have had
major beefs about the oracle approach. For years, there was TAR about
oracle's serializable isolation level *silently allowing partial
transactions to commit*. This had to do with tx's that inserted a row,
then updated it, all in the one tx. If you were just lucky enough
to have the insert cause a page split in the index, the DBMS would
use the old pre-split page to find the newly-inserted row for the
update, and needless to say, wouldn't find it, so the update merrily
updated zero rows! The support guy I talked to once said the developers
wouldn't fix it "because it'd be hard". The bug request was marked
internally as "must fix next release" and oracle updated this record
for 4 successive releases to set the "next release" field to the next
release! They then 'fixed' it to throw the 'cannot serialize' exception.
They have finally really fixed it.( bug #440317 ) in case you can
access the history. Back in 2000, Tom Kyte reproduced it in 7.3.4,
8.0.3, 8.0.6 and 8.1.5.
Now my beef is with their implementation of XA and what data they
lock for in-doubt transactions (those that have done the prepare, but
have not yet gotten a commit). Oracle's over-simple logging/locking is
currently locking pages instead of rows! This is almost like Sybase's
fatal failure of page-level locking. There can be logically unrelated data
on those pages, that is blocked indefinitely from other equally
unrelated transactions until the in-doubt tx is resolved. Our TAR has
gotten a "We would have to completely rewrite our locking/logging to
fix this, so it's your fault" response. They insist that the customer
should know to configure their tables so there is only one datarow per
page.
So for historical and current reasons, I believe Oracle is absolutely
the dominant DBMS, and a winner in the market, but got there by being first,
sold well, and by being good enough. I wish there were more real market
competition, and user pressure. Then oracle and other DBMS vendors would
be quicker to make the product better.
Joe -
How to set isolation level for BMP
Hi.
We're trying to avoid the ORA-08177 by setting the isolation level in the weblogic-ejb-jar.xml
to READ_COMMITED
Still (looking in the jdbc.log) it seems that weblogic set the transaction isolation
level to SERIALIZABLE
The xml :
<weblogic-enterprise-bean>
<ejb-name>Account</ejb-name>
<caching-descriptor>
<max-beans-in-cache>100</max-beans-in-cache>
<idle-timeout-seconds>600</idle-timeout-seconds>
<cache-strategy>Read-Write</cache-strategy>
</caching-descriptor>
<persistence-descriptor>
<delay-updates-until-end-of-tx>true</delay-updates-until-end-of-tx>
<finders-call-ejbload>false</finders-call-ejbload>
</persistence-descriptor>
<clustering-descriptor>
<home-is-clusterable>false</home-is-clusterable>
<home-load-algorithm>round-robin</home-load-algorithm>
</clustering-descriptor>
<enable-call-by-reference>false</enable-call-by-reference>
<jndi-name>Account</jndi-name>
<transaction-isolation>
<isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
<method><ejb-name>Account</ejb-name><method-name>*</method-name></method>
</transaction-isolation>
</weblogic-enterprise-bean>
RegardsWhen I marked all the beans with READ_COMMITED it works.
-
Is there a configuration parameter that controls the default isolation level used by distributed transactions when you configure XA support on Oracle 8i? I know Oracle's default isolation level is READ COMMITTED, but I would like to have SERIALIZABLE as the isolation level for transactions that are initiated from some MS COM+ components accessing the database.
Thanks,
SamIan,
The default for Oracle (any version) is ReadCommitted. The only other
isolation level Oracle supports is Serializable but it's implemented in
such a way that you will be allowed to continue until commit time and
only then you might get an exception stating the the access for that
transaction could not be serialized.
I don't know for the jDriver but if you use the Oracle Thin XA driver
even if you set the isolation level in your descriptor you will get an
exception from Weblogic. It is a Weblogic bug and you can contact
[email protected] to get a patch.
Regards,
Dejan
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? -
Restore default isolation level fails with connection in pool
Hi,
I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
It has to be possible to change the isolation level for transaction, isn´t it?
Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
ConnectionManager connectionManager = new ConnectionManager();
Connection con = null;
int transactionIsolationLevel = 0;
Queue queue = null;
List list = null;
try {
con = connectionManager.getConnection();
transactionIsolationLevel = con.getTransactionIsolation();
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
// auskommentiert für RE
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
con.setAutoCommit( false );
QueueManager queueManager = new QueueManager();
list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
con.commit();
} catch (ClassNotFoundException cnfe) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
handleExceptions(queue, cnfe);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (SQLException sqle) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
handleExceptions(queue, sqle);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (QueueManagerException qme) {
logger.error(LOGLOC + "Exception executing queue manager!", qme);
handleExceptions(queue, qme);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} finally {
try {
con.setAutoCommit(true);
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
// Auskommentiert für RE
con.setTransactionIsolation( transactionIsolationLevel );
con.close();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);
The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
Any hints, solutions?Hi,
I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
It has to be possible to change the isolation level for transaction, isn´t it?
Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
ConnectionManager connectionManager = new ConnectionManager();
Connection con = null;
int transactionIsolationLevel = 0;
Queue queue = null;
List list = null;
try {
con = connectionManager.getConnection();
transactionIsolationLevel = con.getTransactionIsolation();
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
// auskommentiert für RE
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
con.setAutoCommit( false );
QueueManager queueManager = new QueueManager();
list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
con.commit();
} catch (ClassNotFoundException cnfe) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
handleExceptions(queue, cnfe);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (SQLException sqle) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
handleExceptions(queue, sqle);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (QueueManagerException qme) {
logger.error(LOGLOC + "Exception executing queue manager!", qme);
handleExceptions(queue, qme);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} finally {
try {
con.setAutoCommit(true);
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
// Auskommentiert für RE
con.setTransactionIsolation( transactionIsolationLevel );
con.close();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);
The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
Any hints, solutions? -
Bug in Oracle's handling of transaction isolation levels?
Hello,
I think there is a bug in Oracle 9i database related to serializable transaction isolation level.
Here is the information about the server:
Operating System: Microsoft Windows 2000 Server Version 5.0.2195 Service Pack 2 Build 2195
System type: Single CPU x86 Family 6 Model 8 Stepping 10 GenuineIntel ~866 MHz
BIOS-Version: Award Medallion BIOS v6.0
Locale: German
Here is my information about the client computer:
Operaing system: Microsoft Windows XP
System type: IBM ThinkPad
Language for DB access: Java
Database information:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
The database has been set up using the default settings and nothing has been changed.
To reproduce the bug, follow these steps:
1. Create a user in 9i database called 'kaon' with password 'kaon'
2. Using SQL Worksheet create the following table:
CREATE TABLE OIModel (
modelID int NOT NULL,
logicalURI varchar (255) NOT NULL,
CONSTRAINT pk_OIModel PRIMARY KEY (modelID),
CONSTRAINT logicalURI_OIModel UNIQUE (logicalURI)
3. Run the following program:
package test;
import java.sql.*;
public class Test {
public static void main(String[] args) throws Exception {
java.util.Locale.setDefault(java.util.Locale.US);
Class.forName("oracle.jdbc.OracleDriver");
Connection connection=DriverManager.getConnection("jdbc:oracle:thin:@schlange:1521:ORCL","kaon","kaon");
DatabaseMetaData dmd=connection.getMetaData();
System.out.println("Product version:");
System.out.println(dmd.getDatabaseProductVersion());
System.out.println();
connection.setAutoCommit(false);
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
int batches=0;
int counter=2000;
for (int outer=0;outer<50;outer++) {
for (int i=0;i<200;i++) {
executeUpdate(connection,"INSERT INTO OIModel (modelID,logicalURI) VALUES ("+counter+",'start"+counter+"')");
executeUpdate(connection,"UPDATE OIModel SET logicalURI='next"+counter+"' WHERE modelID="+counter);
counter++;
connection.commit();
System.out.println("Batch "+batches+" done");
batches++;
protected static void executeUpdate(Connection conn,String sql) throws Exception {
Statement s=conn.createStatement();
try {
int result=s.executeUpdate(sql);
if (result!=1)
throw new Exception("Should update one row, but updated "+result+" rows, query is "+sql);
finally {
s.close();
The program prints the following output:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.lang.Exception: Should update one row, but updated 0 rows, query is UPDATE OIModel SET logicalURI='next2571' WHERE modelID=2571
at test.Test.executeUpdate(Test.java:35)
at test.Test.main(Test.java:22)
That is, after several iterations, the executeUpdate() method returns 0, rather than 1. This is clearly an error.
4. Leave the database as is. Replace the line
int counter=2000;
with line
int counter=4000;
and restart the program. The following output is generated:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)
at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)
at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
at test.Test.executeUpdate(Test.java:33)
at test.Test.main(Test.java:22)
This is clearly an error - only one transaction is being active at the time, so there is no need for serialization of transactions.
5. You can restart the program as many times you wish (by chaging the initial counter value first). The same error (can't serialize access for this transaction) will be generated.
6. The error doesn't occur if the transaction isolation level isn't changed.
7. The error doesn't occur if the UPDATE statement is commented out.
Sincerely yours
Boris MotikI have a similar problem
I'm using Oracle and serializable isolation level.
Transaction inserts 4000 objects and then updates about 1000 of these objects.
Transactions sees inserted objects but cant update them (row not found or can't serialize access for this transaction are thrown).
On 3 tries for this transaction 1 succeds and 2 fails with one of above errors.
No other transactions run concurently.
In read commited isolation error doesn't arise.
I'm using plain JDBC.
Similar or even much bigger serializable transaction works perfectly on the same database as plsql procedure.
I've tried oci and thin (Oracle) drivers and oranxo demo (i-net) driver.
And this problems arises on all of this drivers.
This problem confused me so much :(.
Maby one of Oracle users, developers nows cause of this strange behaviour.
Thanx for all answers. -
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 -
Transaction Isolation Levels in weblogic-cmp-rdbms-jar.xml
Hi All,
Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
isolation levels for the methods in the
weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
the isolation levels in these two ways.
Help me asap.The CMP setting has been deprecated. You can set it for all types of
EJBs in the weblogic-ejb-jar.xml
-- Rob
chandru wrote:
Hi All,
Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
isolation levels for the methods in the
weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
the isolation levels in these two ways.
Help me asap. -
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...
>
>
>
>
-
Setting transaction isolation levels in WAS5
I think I'm missing something pretty easy. How can I set the isolation
levels for the containter managed transactions on my beans?
Specifically, I want to set soem lookup methods on my Sessions beans
to TRANSACTION_REPEATABLE_READ. I've already put the
container-transaction blocks in my ejb-jar.xml
Does Websphere 5 have something akin to WebLogic's
weblogic-ejb-jar.xml where you can set additional parameters like
this? Do I have to use a tool like WSAD to specify this? The AAT
doesn't seem to have this option.
Thanks,
James LynnHi Slava, Ryan,
We haven't looked at 8.1 yet since our release cycle wouldn't allow us
to move to 8.1 until at least June anyway, but even if the problems was
fixed there it took BEA support more than 6 months (I opened the case on
Sep 23 2002 and only this week I got the patch that I haven't even tried
to test to see if it works) to issue a patch for such a small problem.
The server would just check if the Oracle XA driver was being used and
no matter what version would just throw an exception if you try to set
the transaction isolation level saying that the feature in the Oracle
8.1.7 driver was broken... (although you might be using 9.x or even a
pre-8.1.7 driver)...
So this is about it.
And Slava, I've tried pushing a case harder only to end up with BEA
support trying to convince me that I was misinterpreting the JDBC spec
when it was not true, so I just gave up. The main goal of BEA support in
all of our experience has been that they don't try to solve the cases
but close them.
That's my and some of my colleagues personal views anyway, you don't
have to share them.
Regards,
Dejan
Slava Imeshev wrote:
Hi Deyan,
Sorry for the delay. Could you give us more details about CR090104?
I've got some feedback in XA area, not sure if it was a related case.
Also, I've never had any problems with weblogic CCE, so you may want
to push your case a little harder.
As per the bold statement - the initial question was about functionality
available in weblogic but not available in websphere - it can't be more
bold :)
Regards,
Slava Imeshev
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
This is a very bold statement Slava, considering that with Oracle XA
driver you cannot even set the transaction isolation level because of a
Weblogic bug (CR090104 that has been open for more than 6 months
already)...
Dejan
Slava Imeshev wrote:
Hi James,
"James F'jord Lynn" <[email protected]> wrote in message
news:[email protected]...
I think I'm missing something pretty easy. How can I set the isolation
levels for the containter managed transactions on my beans?
Specifically, I want to set soem lookup methods on my Sessions beans
to TRANSACTION_REPEATABLE_READ. I've already put the
container-transaction blocks in my ejb-jar.xml
Does Websphere 5 have something akin to WebLogic's
weblogic-ejb-jar.xml where you can set additional parameters like
this? Do I have to use a tool like WSAD to specify this? The AAT
doesn't seem to have this option.
My guess here is that it's a signal that this is a last chance
for you to abandon WebSphere and return back to WebLogic's
safe harbor.
Regards,
Slava Imeshev
Maybe you are looking for
-
How can I transfer music from iphone 3g to a new iPad?
My son is trying to transfer music not purchased from iTunes, from his iPhone 3 to a New iPad. He does not have access to a computer, how can this be done? Thanks
-
JDBC datasoure that works for embedded OC4J server of JDeveloper 10.1.3.4
Hi all, I have this in the Application Module as JDBC datasource: java:comp/env/jdbc/DBCON That works fine if I deploy the application on Oracle application- or tomcat-server. On the connections tab in JDeveloper I have made a database connection wit
-
Block material at material type(HIBE) level for movement type "261" & "261"
Hi, Block material at material type(HIBE) level for movement type "261" & "261". Requirement: This material type should not issued to the PM orders using above mvt types. regards, Venkatesan Anandan
-
hii experts, Account determination is major concern in SAP. Whether account determination will be done only SAP MM consultant or any other module responsibilities in account determination? Becas SAP has more business scenario , each will have account
-
Hide/remove the fields from the time accounts table on the screen of approval leave request
Hi, i want to remove or hide the fields from the following table . is there anybody who know how to do? help me pls! Thanks in advance