Changing isolation level in a session, is valid please see following situation i have used shapshot.

hi,
--DBCC FREEPROCCACHE
--DBCC DROPCLEANBUFFERS
CREATE TABLE #temp(ID BIGINT NOT NULL)
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
INSERT INTO #temp (id) SELECT wid FROM w WHERE ss=1
UPDATE w SET ss =0 WHERE wid IN (SELECT id FROM #Temp)
COMMIT TRAN
IF (EXISTS(SELECT * FROM #temp))
BEGIN
SELECT 'P'
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
insert into a ( a,b,c)
SELECT a , b ,c FROM w WHERE wid= 104300001201746884
COMMIT TRAN
END
Q1) changin isolation in this way is correct or not?
Q2) why i have chainged isolation is , because
this stmt was updated by other trnsaction also, and i also wanted to udpate it , so i made one repetable read and then snapshot.
UPDATE w SET ss=0 WHERE wid IN (SELECT id FROM #Temp)
DROP TABLE #temp
yours sincerley

http://blogs.msdn.com/b/craigfr/archive/2007/05/16/serializable-vs-snapshot-isolation-level.aspx
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Similar Messages

When I send an e-mail to a group address, from my address book, I get an error messageI get an error message that one of them is not a valid e-mail address, although I have used it alone without any problem.

When I send an e-mail to a group address, from my address book, I get an error messageI get an error message that one of them is not a valid e-mail address, although I have used it alone without any problem.

See https://support.mozilla.org/en-US/questions/1018363

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

Galen 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

Setting transaction isolation level in a session bean

Hi all!
In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
The idea is to prevent lost update on database when multiple accesses occur concurrently.
Thanks in advance for your patience,
Tommaso

Hi all!
In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
The idea is to prevent lost update on database when multiple accesses occur concurrently.
Thanks in advance for your patience,
Tommaso

TX isolation level with stateless session bean in oc4j

Hi All,
I have a stateless session bean with container managed transaction method. This method is called in a Servlet. This method retrieves data from database using 'ejb-location'connection pool and closes the connection inside. Max-connection setting for connection pool is 50
I am facing a problem running servlet multiple times.
When i have the tx_attribute as Supports, it works fine. I can run the servlet hundreds of times
But when i have the tx_attribute as Required, i am able to run servlet only 50 times and further it says 'Max connection limit exceed..unable to get the connection'.
I assume that with 'Required' attribute, it starts a transaction. Why is the transaction not getting completed at end of method? Is transaction hanging somewhere?
I assume that i am closing the connection properly as it is working fine with supports attribute.
When i monitor database, there are only 20 connections.
Why am i seeing this behaviour?
Thanks
srinath

Hi Deepak,
Thanks for your reply.
Actually, our stand alone java application already using spring-hibernate feature. Now we are planning divide our application into modules and deploy each module as ejb beans. As it is already integrated with spring-hibernate we are not using entity beans as of now. My understanding is container uses some default transcation management .so, my question is what are all the configurations needs to be done to let weblogic 10.0 server uses org.springframework.orm.hibernate3.HibernateTransactionManager. I mean, is there are any .xml file in weblogic to configure all these? please reply deepak I am struck here..
Regards,
Rushi.

Transaction Isolation Level to Read UnCommited in Non OLTP Database

HI,
We are having a database which for NOT OLTP process. That is OLAP DB. Operation on that DB is only Select and (Incremental Insert - FOR DWH ) not Update/Delete and we are performing ROLAP operations in that DB.
By Default SQL Server DB isolation Level is READ COMMITTED.AS Our DB IS OLAP SQL Server DB we need to change the isolation level toRead Uncommited. We google it down but We can achive in
Transaction level only by SET isoaltion Level TO Read UNCOMMITED
or ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Is there any other way if we can Change the Database isolation level to READ uncommitedfor Entire Database?, insteads of achiving in Transaction Level or With out enabling SET ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Please use Marked as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
Please use Marked as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

Hi,
My first question would be why do you want to change Isolation level to read uncommitted, are you aware about the repercussions you will get dirty data, a wrong data.
Isolation level is basically associated with the connection so is define in connection.
>> Transaction level only by SET isoaltion Level TO Read UNCOMMITED or ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Be cautious Read UNCOMMITED and Snapshot isolation level are not same.The former is pessimistic Isolation level and later is Optimistic.Snapshot isolation levels are totally different from read uncommitted as snapshot Isolation level
uses row versioning.I guess you wont require snapshot isolation level in O:AP DB.
Please read below blog about setting Isolation level Server wide
http://blogs.msdn.com/b/ialonso/archive/2012/11/26/how-to-set-the-default-transaction-isolation-level-server-wide.aspx
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers
My TechNet Wiki Articles

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.

BMT - Setting Isolation Level

          (I posted this in ejb but didn't really get a solution that works)
          I'm able to set the isolation level of a CMT using weblogic-ejb-jar.xml without
          any problems. Below is a snipet which shows how that:
          <transaction-isolation> <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
          <method> <description><![CDATA[Transaction isolation for StateHandlerMessage]]></description>
          <ejb-name>StateHandlerMessage</ejb-name> <method-name>*</method-name> </method>
          </transaction-isolation>
          That works perfectly for a CMT bean, however it does not seem to work for a BMT.
          I'm using weblogic81 in development mode with an oracle jdriver and it seems my
          BMT bean is getting an isolation level of TRANSACTION_SERIALIZABLE.
          Is this a bug? If not how do I set the isolation level for a BMT bean? (I don't
          think I can using Connection.setIsolationLevel since I don't have a connection
          within my Session and Message Beans)
          thanks!
          lance


          But weblogic.transaction.Transaction does have setProperty method and you should
          be able to use :
          weblogic.transaction.TxHelper.getTransaction().setProperty() to set that property.
          "Lance" <[email protected]> wrote:
          >
          >Thanks for the reply, however javax.transaction.UserTransaction does
          >not have a
          >.setProperty method.
          >
          >Any ideas?
          >
          >lance
          >
          >"asafbu" <[email protected]> wrote:
          >>
          >>
          >>
          >>You set the isolation level for user transactions in the beans java
          >code.
          >>When
          >>the application runs, the transaction is explicitly started.
          >>
          >>
          >>User Transaction tx = (UserTransaction) ctx.lookup("javax.transaction.UserTransaction");
          >>
          >>tx.begin();
          >>
          >>tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
          >> (Connection.TRANSACTION_READ_COMMITED));
          >>....
          >>....
          >>
          >>
          >>
          >>
          >>
          >>"Lance" <[email protected]> wrote:
          >>>
          >>>(I posted this in ejb but didn't really get a solution that works)
          >>>
          >>>I'm able to set the isolation level of a CMT using weblogic-ejb-jar.xml
          >>>without
          >>>any problems. Below is a snipet which shows how that:
          >>>
          >>><transaction-isolation> <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
          >>><method> <description><![CDATA[Transaction isolation for StateHandlerMessage]]></description>
          >>><ejb-name>StateHandlerMessage</ejb-name> <method-name>*</method-name>
          >>></method>
          >>></transaction-isolation>
          >>>
          >>>That works perfectly for a CMT bean, however it does not seem to work
          >>>for a BMT.
          >>>I'm using weblogic81 in development mode with an oracle jdriver and
          >>it
          >>>seems my
          >>>BMT bean is getting an isolation level of TRANSACTION_SERIALIZABLE.
          >>
          >>>
          >>>Is this a bug? If not how do I set the isolation level for a BMT bean?
          >>> (I don't
          >>>think I can using Connection.setIsolationLevel since I don't have a
          >>connection
          >>>within my Session and Message Beans)
          >>>
          >>>thanks!
          >>>
          >>>lance
          >>>
          >>
          >

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

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

Oracle XA driver and isolation level

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

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

Is it possible to change sound level up size in IOS 7 ??

Hi,
I want to know if it is possible to change sound level up icon like image below:
Please tell me if it is possible to resize it or to change icon position.

Not possible.

I am attempting to use my new adobe photoshop elements 12. I asked for a serial number per instructions, typed in the serial number and am being told it's not valid- please help.

I am attempting to use my new adobe photoshop elements 12. I asked for a serial number per instructions, typed in the serial number and am being told it's not valid- please help

First make sure you are using the correct code for the serial number. To locate the serial number:
http://helpx.adobe.com/x-productkb/global/find-serial-number.html
http://helpx.adobe.com/x-productkb/policy-pricing/serial-number-retrieval-process-faq.html
https://redeem.licenses.adobe.com/getserial
If you still have a problem you can contact Adobe Support using chat and they might be able to assist you.
Serial number and activation chat support (non-CC)
http://helpx.adobe.com/x-productkb/global/service1.html ( http://adobe.ly/1aYjbSC )

How do you determine a process or sessions isolation level.

We are using COM+ components to issue database statements against an Oracle 8i database. COM+ has a property that allows you to set the isolation level. Is there any tool or query that would allow me to verify the isolation level in use by a session or process? I want to verify this property is actually affecting the connection to the DB.
Thanks,
Sam

FLAG is just one of those columns that Oracle uses. It isn't documented but, as far as I know (which isn't very far), the only use for it is to record the isolation level for the transaction.
I didn't mention it because I didn't think it helped you, for this reason: we don't get a record in the v$transaction view until the transaction has already started. At which point it is too late to change the ISOLATION_LEVEL for the transaction.
Although I suppose you could do this:
BEGIN
   UPDATE dummy_table set col1 = col1;
   -- remember V$TRANSACTION shows all txns
   SELECT count(1) INTO ln
   FROM   v$transaction t, v$session s
   WHERE bitand(t.flag,268435456) <> 0
   AND    s.taddr = t.addr
   AND    s.audsid = sys_context('userenv', 'sessionid');
   IF ln = 0
   THEN
      ROLLBACK;
      SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   END IF;
   -- do_whatever
   COMMIT;
END ;.
Cheers, APC

Why can't I change the transaction isolation level?

I was trying to change the transaction isolation level from an EJB. My source codes are shown as the follows:
======================================================
/*********************** Database Routines *************************/
private void makeConnection() {
try {
InitialContext ic = new InitialContext();
DataSource ds = ( DataSource )ic.lookup( dbName );
con = ds.getConnection();
DatabaseMetaData dmd = con.getMetaData();
show_supported_trans_levels( dmd );
int status = con.getTransactionIsolation();
System.out.print( "1. " );
disp_tx_status( status );
System.out.println( "con.isReadOnly() = " + con.isReadOnly() );
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
System.out.print( "2. " );
disp_tx_status( status );
} catch( SQLException ex ) {
System.err.println( "SQLException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
} catch( NamingException ex ) {
System.err.println( "NamingException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
private void disp_tx_status( int status )
System.out.print( "Transaction Status: " );
switch( status )
case( Connection.TRANSACTION_READ_UNCOMMITTED ):
System.out.println( "TRANSACTION_READ_UNCOMMITTED" );
break;
case( Connection.TRANSACTION_READ_COMMITTED ):
System.out.println( "TRANSACTION_READ_COMMITTED" );
break;
case( Connection.TRANSACTION_REPEATABLE_READ ):
System.out.println( "TRANSACTION_REPEATABLE_READ" );
break;
case( Connection.TRANSACTION_SERIALIZABLE ):
System.out.println( "TRANSACTION_SERIALIZABLE" );
break;
case( Connection.TRANSACTION_NONE ):
System.out.println( "TRANSACTION_NONE" );
break;
default:
System.out.println( "UNKNOWN" );
break;
private void show_supported_trans_levels( DatabaseMetaData dmd ) throws SQLException
System.out.println( "List of Supported Transaction Isolation Levels: " );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_UNCOMMITTED ) )
System.out.println( "TRANSACTION_READ_UNCOMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_UNCOMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_COMMITTED ) )
System.out.println( "TRANSACTION_READ_COMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_COMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_REPEATABLE_READ ) )
System.out.println( "TRANSACTION_REPEATABLE_READ is supported!" );
else
System.out.println( "TRANSACTION_REPEATABLE_READ is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_SERIALIZABLE ) )
System.out.println( "TRANSACTION_SERIALIZABLE is supported!" );
else
System.out.println( "TRANSACTION_SERIALIZABLE is unsupported!" );
=========================================================
However, I encountered the following exception when running at the highlighted statement:
======================================================
SQLException: java.sql.SQLException: Transaction manager errors. statement not allowed in XA Session.
======================================================
To my surprise, the isolation level TRANSACTION_SERIALIZABLE is supported from the database vendor. So why can't I change the transaction isolation level?

You can change the setting, you may need to click the lock at the bottom of the preference pane. Be careful what you download and install, Gatekeeper is there to help you. OS X: About Gatekeeper - Apple Support

Changing isolation level in a session, is valid please see following situation i have used shapshot.

Similar Messages

Maybe you are looking for