Writing BLOB under Trasnaction Isolation level Serializable

I am trying to update a BLOB datatype using JDBC.
Steps:
1. Select the Row FOR UPDATE
2. Get hold of BLOB Object
3. Get Binary Ouput Stream
4. Write to Output Stream
This is being done inside a bigger Trasnaction. This is working fine when Transaction Isolation level is READ COMMITTED.
But when I am using Transaction Isolation level SERIALIZABLE, it behave in very inconsistent manner.
Sometimes it gets updated. Other times, it gives an error stating 'Cannot serialize this Transaction'.
Whats the reason and possible solution?

Hi Kamal,
The SERIALIZABLE degree of isolation has its own limitations and one of them is the ORA-08177 error. This message is displayed whenever an attempt is made to update a row that has changed since your transaction began.
So probably you should be looking if there are transactions that are simultaneously trying to update the same row. I don't think you need simulataneous access for a row if you are doing SERIALIZABLE transaction.This link would be helpful to you.
http://asktom.oracle.com/pls/ask/f?p=4950:8:11007064320210057726::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:3233191441609
perhaps if you post part of your code here which does the update then we might be able to help you more.
Thanks,
khalid

Similar Messages

Problems in using isolation level serializable

Dear everyone:
This is the problem I met while using isolation level
serializable in ORALCE 8.0.3 for Netware:
Program 1 Program2
Insert record 1 into table 1
select record 1 from table1
commit
select record1 from table1
insert record 2 into table1
select record2 from table1
commit
select record2 from table1
update record2 from table1
commit
delete record2 from table1
commit
update record1 from table1
*ORA-8177 cannot serialize
access for this transaction
According to my understanding to the serialization isolation
level, it should not occurs.
Anyone can give me some ideas?
Regards!
null

Dear everyone:
This is the problem I met while using isolation level
serializable in ORALCE 8.0.3 for Netware:
Program 1 Program2
Insert record 1 into table 1
select record 1 from table1
commit
select record1 from table1
insert record 2 into table1
select record2 from table1
commit
select record2 from table1
update record2 from table1
commit
delete record2 from table1
commit
update record1 from table1
*ORA-8177 cannot serialize
access for this transaction
According to my understanding to the serialization isolation
level, it should not occurs.
Anyone can give me some ideas?
Regards!
null

Isolation level SERIALIZABLE problem

Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure

Marcel,
First of all, I'd be interested in hearing why you think you need serializable transactions (why 'read committed' doesn't work for your application). In the 8 years I've been building Oracle apps, I've never deemed it necessary to use serializable transactions. Maybe an optimistic locking strategy will solve your problem.
Secondly, if I were designing the interface, I wouldn't have a procedure in charge of both executing business logic AND retrying the logic in case of failure. I'd build a helper procedure that calls the procedure that does the work, looks for certain exceptions, and retries the procedure when necessary.
Lastly, if your interface doesn't have transactional control (the caller is in charge of commits and rollbacks), maybe you should simply attempt the update statement and throw an exception to the caller and let them handle it.
I'm sorry if I haven't directly solved your problem, but sometimes the best way to solve a problem is to question the decisions that got you there in the first place.
Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure

XI JDBC adapter isolation level serializable - Not working properly????

Hi all,
I have a JDBC sender adapter which perform in Transaction isolation Method serializable(Advance Mode settings) but it seems that it updates the wrong records witch results in records no to be send in XI.
the select statement I am using is
select OwnerCode,DeliveryNo , ErpWarehouseCode, TrtCode, PostGIdate, PostGIdateChangedFlg, DocumentNo, DocumentDate, CancelFlg, PostGIFlg, TacticalRouteCode, LicenceNo, PackagesQty, CusPickUpFlg, CusPickUpChangedFlg, RouteChangedFlg, DlvPriority, PickingDate, PickingDateChangedFlg, DlvPriorityChangedFlg, OdtLineNumber, ItemCode, WmsStatusCode, Lot, ExpirationDate,ProductionDate, TraUnitQty, TraUnitCode, Qty, MainUnitCode, ConvFactor, ConvDivisor, InitQty, DocQty, DeleteLineFlg, ParentLineNumber, ItemType, CusPickUpDescr, CusPickUpChangedFlg2
from wmsConfDlv2ERP
where flg = 0 and
         DeliveryNo in ( select top 1 DeliveryNo from wmsConfDlv2ERP where flg = 0 )
and the update is
UPDATE wmsConfDlv2ERP set flg = -1
where flg = 0 and
          DeliveryNo in ( select top 1 DeliveryNo from wmsConfDlv2ERP where flg = 0 )
Any ideas? The DB is an MS SQL 2005... Thanks.

Hi,
As far as I know, the JDBC adapter does not support nested queries (just my experience). I always used SPs to properly handle the situation and flow logic.
VJ

Isolation level serializable + EntityFramework 6.0 Concurrent Add

Hi!
I'm new to database programming and entity framework and currently running into
some database behavior I don't understand. Maybe someone can explain it to me?
I'm using a very simple table to isolate the behavior:
ID(Primary Key), SSI(Indexed, duplicates allowed)
        static void AddTalkgroups(object state)
            for (int i = 0; i < 1000; i++)
                Talkgroup talk = new Talkgroup();
                talk.ID = Guid.NewGuid();
                talk.SSI = i;
                using (var context = new LeitstelleContext())
                    using (var transaction = context.Database.BeginTransaction(System.Data.IsolationLevel.Serializable))
                       // context.Database.Log = ShowCache;
                        try
                            if (context.Talkgroups.SingleOrDefault(t => t.SSI == i) == null)
                                context.Talkgroups.Add(talk);
                                context.SaveChanges();
                            transaction.Commit();
                            Console.Write("+");
                        catch (Exception e)
                            transaction.Rollback();
                            Console.Write("-");
If I start the method in 2 concurrent threads, one of both will run into deadlocks
over and over again. As intended, no duplicates of SSI are added, but I don't understand
the database behavior.(The deadlocks)
As far as I understand. The database should place a RangeI-N lock on datasets
not found in the table during the "transaction" so no other transactions would be able
to add a new dataset matching the "select"-statement of the active transaction.
If I issue a "sp_lock" command during the transaction I'm seeing some RangeS-S locks.
thanks alot for looking into this!
best regards
Johnny

Hi David!
If I just switch to IsolationLevel.ReadCommited I get 968 duplicates in
my example. (And no PK violations)
Talkgroup.Id = PrimaryKey
Talkgroup.Ssi is configured as "ununique index" in the SQL-Server 2012.
class Program
        static object lockobject = new object();
        static Barrier barrier = new Barrier(3);
        static void Main(string[] args)
            LeitstelleContext context = new LeitstelleContext();
            //Talkgroup talk = new Talkgroup();
            //talk.ID = Guid.NewGuid();
            //talk.SSI = 1234;
            //context.Talkgroups.Add(talk);
            //context.SaveChanges();
            context.Database.ExecuteSqlCommand("delete Talkgroups");
            DateTime start = DateTime.Now;
            System.Threading.ThreadPool.QueueUserWorkItem(AddTalkgroups);
            System.Threading.ThreadPool.QueueUserWorkItem(AddTalkgroups);
            barrier.SignalAndWait();
            Console.WriteLine(DateTime.Now.Subtract(start).TotalSeconds.ToString());
            var liste = context.Talkgroups.GroupBy(t => t.SSI).Where(mygroup => mygroup.Count() > 1);
            Console.WriteLine(liste.Count().ToString());
            //foreach (var item in liste)
            //    Console.WriteLine(item.Key);
            Console.ReadLine();
        static void AddTalkgroups(object state)
            for (int i = 0; i < 1000; i++)
                ////context.Database.Log = ShowCache;
                //Parallel.For(6500, 7500, i =>
                Talkgroup talk = new Talkgroup();
                talk.ID = Guid.NewGuid();
                talk.SSI = i;
                using (var context = new LeitstelleContext())
                    using (var transaction = context.Database.BeginTransaction(System.Data.IsolationLevel.ReadCommitted))
                       // context.Database.Log = ShowCache;
                        try
                            if (context.Talkgroups.SingleOrDefault(t => t.SSI == i) == null)
                                context.Talkgroups.Add(talk);
                                context.SaveChanges();
                            transaction.Commit();
                            Console.Write("+");
                        catch (Exception e)
                            transaction.Rollback();
                            Console.Write("-");
            barrier.SignalAndWait();
br
Johnny

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

Setting transaction isolation level in Weblogic 5.1

          Hi,
          I'm using Weblogic server5.1 and i'm trying to set the isolation level on one
          of my session bean. Below is the code :
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>chargeMgr</ejb-name>
          <jndi-name>chargeMgr</jndi-name>
          <transaction-isolation>
          <isolation-level>Serializable</isolation-level>
          <method>
          <ejb-name>chargeMgr</ejb-name>
          <method-intf>Remote</method-intf>
          <method-name>*</method-name>
          </method>
          </transaction-isolation>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          I have checked the syntax against the weblogic documentation.
          However, when i try to jar the beans up into the jar file (weblogic.ejbc), it
          give me the following error :
          org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean" allows no further
          input; "transaction-isolation" is not allowed.
          Can anyone help?
          Regards.


yes, only in weblogic-ejb-jar.xml , and you can see that from the DTD
          source.
          thanks
          Yu
          "cw lee" <[email protected]> wrote in message
          news:[email protected]...
          >
          > thanks for ur advice.
          >
          > one thing i forgot to mention is that the isolation-level was specified in
          weblogic-ejb-jar.xml.
          > Do u mean that it must be placed in weblogic-cmp-rdbms-jar.xml and not
          weblogic-ejb-jar.xml
          > ?
          >
          > Are the codes u suggested to be in weblogic-ejb-jar.xml or
          weblogic-cmp-rdbms-jar.xml
          > ?
          >
          > Regards.
          >
          >
          >
          > "Yu Tian" <[email protected]> wrote:
          > >the right name for Seriealizable should be: TRANSACTION_SERIALIZABLE.
          > >so the
          > >DD looks like:
          > >
          > ><?xml version="1.0"?>
          > >
          > ><!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic
          > >5.1.0
          > >EJB//EN' 'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>
          > >
          > ><weblogic-ejb-jar>
          > > <weblogic-enterprise-bean>
          > > <ejb-name>containerManaged</ejb-name>
          > > <caching-descriptor>
          > > <max-beans-in-cache>1000</max-beans-in-cache>
          > > </caching-descriptor>
          > > <persistence-descriptor>
          > > <persistence-type>
          > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
          > > <type-version>5.1.0</type-version>
          > > <type-storage>META-INF/weblogic-cmp-rdbms-jar.xml</type-storage>
          > > </persistence-type>
          > > <persistence-use>
          > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
          > > <type-version>5.1.0</type-version>
          > > </persistence-use>
          > > </persistence-descriptor>
          > > <jndi-name>containerManaged.AccountHome</jndi-name>
          > > <transaction-isolation>
          > > <isolation-level>TRANSACTION_SERIALIZABLE</isolation-level>
          > > <method>
          > > <ejb-name>containerManaged</ejb-name>
          > > <method-name>*</method-name>
          > > </method>
          > > </transaction-isolation>
          > > </weblogic-enterprise-bean>
          > > </weblogic-ejb-jar>
          > >
          > >Thanks
          > >
          > >Yu
          > >
          > >
          > >"cw lee" <[email protected]> wrote in message
          > >news:[email protected]...
          > >>
          > >> Hi,
          > >>
          > >> I'm using Weblogic server5.1 and i'm trying to set the isolation level
          > >on
          > >one
          > >> of my session bean. Below is the code :
          > >>
          > >> <weblogic-ejb-jar>
          > >> <weblogic-enterprise-bean>
          > >> <ejb-name>chargeMgr</ejb-name>
          > >> <jndi-name>chargeMgr</jndi-name>
          > >> <transaction-isolation>
          > >> <isolation-level>Serializable</isolation-level>
          > >> <method>
          > >> <ejb-name>chargeMgr</ejb-name>
          > >> <method-intf>Remote</method-intf>
          > >> <method-name>*</method-name>
          > >> </method>
          > >> </transaction-isolation>
          > >> </weblogic-enterprise-bean>
          > >> </weblogic-ejb-jar>
          > >>
          > >> I have checked the syntax against the weblogic documentation.
          > >> However, when i try to jar the beans up into the jar file
          (weblogic.ejbc),
          > >it
          > >> give me the following error :
          > >>
          > >> org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean"
          allows
          > >no further
          > >> input; "transaction-isolation" is not allowed.
          > >>
          > >> Can anyone help?
          > >>
          > >> Regards.
          > >>
          > >
          > >
          >

Transaction Isolation Levels

Hi Everyboody.
Oracle docs. say that Oracle supports three isolation levels and the isolation level should be set before the transaction begins with the SET TRANSACTION ISOLATION LEVEL .....
Resource: http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/server.920/a96524/c21cnsis.htm#2641
But I find that Oracle 9i supports only two isolation levels, viz. Read Committed and Serializable.
SQL> SET TRANSACTION ISOLATION LEVEL READ ONLY
2 ;
SET TRANSACTION ISOLATION LEVEL READ ONLY
ERROR at line 1:
ORA-02179: valid options: ISOLATION LEVEL { SERIALIZABLE | READ COMMITTED }
Is READ ONLY isolatin level avalilable in Oracle 9i or is there any problem with my SET instruction?
Please help me at the earliest.
Have a nice day!
Kishore

Thanks Dmitry.
It works.
Continuing on the same thread, I would like to know what is the difference between READ COMMITTED and SERIALIZABLE isolation levels?
Thank you for your reply.
Kishore.

How to set the isolation level on Entity EJBs

I am using 10.1.3.3 of the OC4J app server.
I am creating an application that uses EJB 2.1.
I am trying to set the isolation levels on the EJBs to either serializable or repeatable read.
When i deploy the EAR file from the OC4J admin console, i can set the isolation level property on the EJB's however when i inspect the orion-ejb-jar.xml file I do not see the isolation level being set. Furthermore, i tried to manually change the isolation setting by editing the orion-ejb-jar.xml and adding the isolation="serialiable" attribute on the entity bean descriptor. I then stopped and restarted the server. I noticed that my change was no longer in the file.
Can someone please let me know how to solve this problem and set the isolation level on Entity EJBs . Thanks

I find it at ejb.pdf from BEA.
          The transaction-isolation stanza can contain the elements shown here:
          <transaction-isolation>
          <isolation-level>Serializable</isolation-level>
          <method>
          <description>...</description>
          <ejb-name>...</ejb-name>
          <method-intf>...</method-intf>
          <method-name>...</method-name>
          <method-params>...</method-params>
          </method>
          </transaction-isolation>
          "Hyun Min" <[email protected]> wrote in message
          news:3c4e7a83$[email protected]..
          > Hi!
          >
          > I have a question.
          > How to set the transaction isolation level using CMT in descriptor?
          >
          > The Isolation level not supported in CMT?
          >
          > Thanks.
          > Hyun Min
          >
          >

Isolation Level bug

ODP.Net ignores the Isolation level of the ambient transaction (TransactionScope). ODP always use ReadCommitted. When the connection string option
Promotable Transaction = local
ODP internally creates an OracleTransaction. Looking inside the OracleConnection.Open method you can see something like this
this.m_oraTransaction = this.BeginTransaction();
BeginTransaction use de default Oracle Isolation level which is ReadCommited.
With a real distributed transacton it's no easy to see the bug but I get the same problem: always ReadCommitted.

This is my DBConnectionManager class. I tried to solve this problem just changing DBConnectionManager, transparent to application.
public class DBConnectionManager
private static List<string> _transacciones = new List<string>();
public static OracleConnection GetConnection()
SetProperIsolationLevel();
return new OracleConnection(GetConnectionString());
private static string GetConnectionString()
return ConfigurationManager.AppSettings["ConnectionString"];
private static void SetProperIsolationLevel()
if((Transaction.Current !=null)&&(Transaction.Current.IsolationLevel == System.Transactions.IsolationLevel.Serializable) && !_transacciones.Contains(Transaction.Current.TransactionInformation.LocalIdentifier))
OracleConnectionStringBuilder csBuilder = new OracleConnectionStringBuilder(GetConnectionString());
csBuilder.Pooling = false;
OracleConnection conn = new OracleConnection(csBuilder.ConnectionString);
conn.Open();
OracleCommand cmd = null;
try
cmd = conn.CreateCommand();
cmd.CommandType = CommandType.Text;
cmd.CommandText = "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE";
cmd.ExecuteNonQuery();
transacciones.Add(Transaction.Current.TransactionInformation.LocalIdentifier);
Transaction.Current.TransactionCompleted += delegate(object sender, TransactionEventArgs e)
_transacciones.Remove(e.Transaction.TransactionInformation.LocalIdentifier);
finally
if(cmd != null)
cmd.Dispose();
conn.Dispose();
}

Setting Isolation levels

We have a window service which is responsible to send SMS to users.
We have 20 instance running as a window service which hits a single table “Tab1”.
I have implemented isolation level – “SET TRANSACTION ISOLATION LEVEL SERIALIZABLE”, but it is not working because 20 instance is reading a single record at the same time and thus sending 20 SMS to single user.
I want that if 20 instances read the same record, only one should send the SMS and not all.
Please advice what can be done..
We have these 20 instances to speed up the process of sending SMS from the table... so we cannot just rely on one service

SERIALIZABLE only means that until you commit, SQL Server guarantees that the result set will be the same if you repeat the query. It does not perform any updates or lock a row for reacing by other users.
It sounds like you have some sort of a queue. Thus, you should look into Service Broker.
In the meanwhile you can try:
BEGIN TRANSACTION
SELECT TOP(1) .... FROM SMS_table WITH (READPAST)
-- Send your SMS here
UPDATE tbl SET fetched = 1 WHERE ...
COMMIT TRANSACTIOn
Don't use SERIALIZABLE, but stick to READ COMMITTED.
Erland Sommarskog, SQL Server MVP, [email protected]

Serializable transaction isolation level bugs

Hello!
I would like to know which versions of Oracle database are free or not free of serializable transaction isolation level bugs.
Especially I'm interested in all informations about 440317 bug which is described here: Bug in Oracle's handling of transaction isolation levels?
Thank you very much.

If you are genuinely suffering from 440317 (and not poor design which is the most common cause of ORA-8177, and hence why it's taken so long for this bug to get fixed - originally raised in 7.2.2 !!!) then you will have to wait until 10g R2 sees the light of day.
Cheers, APC

XA and SERIALIZABLE isolation level

Hi,
I'm using JDBC with oracle DB 8.1.6. When I get the physical connection and set transaction isolation level to TRANSACTION_SERIALIZABLE then issue start() on the XAResource instance it gives me error number 24776 "cannot start a new transaction". Without setting isolation level, the transaction would go smoothly. Note that this is the only transaction I have in my small test program. You can test it with the example given in oracle documentation.

Hi,
I'm using JDBC with oracle DB 8.1.6. When I get the physical connection and set transaction isolation level to TRANSACTION_SERIALIZABLE then issue start() on the XAResource instance it gives me error number 24776 "cannot start a new transaction". Without setting isolation level, the transaction would go smoothly. Note that this is the only transaction I have in my small test program. You can test it with the example given in oracle documentation. i don't think you are allowed to set transaction isolation level to Serializable for XA

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

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)

Writing BLOB under Trasnaction Isolation level Serializable

Similar Messages

Maybe you are looking for