Locking Mechanism/Isolation Level with Datastore (Pessimistic) Tr ansactions
What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?
Does the locking mechanism differ across database platforms? I had read
that only shared locks would be used on Microsoft SQL Server.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic transactions?
Thanks,
Sasha Haghani.
What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?Kodo sticks with the default isolation level of the JDBC driver in use
for transactions, as we've found that many drivers act up when assigned
a level manually.
To lock records during pessimistic transactions, SELECT FOR UPDATE is
used. For the most part, it gives good object-level locking, preventing
concurrent modification, even in applications that span multiple JVMs.
Does the locking mechanism differ across database platforms?The locking differs across databases only in that some DBs do not
support SELECT FOR UPDATE (in which case it is still possible to get
optimistic lock exceptions during pessimistic transactions), some DBs
use a different mechanism (SQLServer has a shared lock construct that is
just as good if not better), and some DBs place restrictions on its use
(Oracle and PostgreSQL cannot lock rows when a SELECT DISTINCT is used).
See the 'known bugs and limitations' appendix of the Kodo user guide for
a detailed listing of locking issues with each databse.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic
transactions?The lock column contains a counter to keep track of object versions. As
you suspect, it is used so that during optimistic transactions when no
locking is performed (or during pessimistic transactions on DBs or
queries that can't perform locking), the system is able to detect that
concurrent modification of an object has occurred and throw the proper
exception. This way data integrity is never lost, even without locking.
As an aside, you can always view the SQL generated by Kodo (and by
looking at it get a feel for how the various table columns are used,
etc) by setting a print writer in the
JDBCPersistenceManagerFactory.setLogWriter() method. Kodo will echo all
SQL to the given stream.
Happy coding.
-- Abe White
TechTrader
Similar Messages
-
Isolation level and optimist/pessimist locking
I am using baen managed transaction in which i have set the isolstion level according to my use...
Now whrer does the concept of Optimist/pessimist locking comes if i have set the isolation level(it should be always pessimist locking in this case??) ???I am using baen managed transaction in which i have set the isolstion level according to my use...
Now whrer does the concept of Optimist/pessimist locking comes if i have set the isolation level(it should be always pessimist locking in this case??) ??? -
Setting isolation level with JDriver for Oracle/XA
edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a transaction and that 'Transactions use the transaction isolation level set
on the connection or the default transaction isolation level for the database'.
Does this mean that you shouldn't try to set it programatically (fair enough)
or that you can't set it in the weblogic deployment descriptor either? Also anybody
got any idea what the default is likely to be if you are using an Oracle 9iR2
database? Is this determined by some database setting?IJ wrote:
edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a transaction and that 'Transactions use the transaction isolation level set
on the connection or the default transaction isolation level for the database'.
Does this mean that you shouldn't try to set it programatically (fair enough)
or that you can't set it in the weblogic deployment descriptor either? Also anybody
got any idea what the default is likely to be if you are using an Oracle 9iR2
database? Is this determined by some database setting?The system should honor the setting defined in the deployment descriptor,
however, for oracle it may not be helpful to change it. Oracle provides two
isolation levels. The default is always READ_COMMITTED. The other
setting is SERIALIZABLE, but this hurts performance, and is also problematic
in the way oracle implements it. For instance, even if you set SERIALIZABLE,
oracle will not lock read data. It will allow other transactions to read and/or
alter data trhat another ongoing SERIALIZABLE transaction has read. The
only way to really lock read data in oracle is to issue oracle-specific SQL in
your select: "SELECT ..... FOR UPDATE".
All in all, you should collect a strong case for why you can't proceed with
READ_COMMITTED first. Then you should research oracle's recommendations
(and their problem record) with SERIALIZABLE.
Joe Weinstein at BEA -
Hello,
I'm new to the Oracle environment and have just started using PL/SQL on Oracle 8i. Where can I find info on how Oracle locks data and how transaction isolation levels are used? We've still not recvd our manuals so please any replies referring to manuals are not welcome!You could move forward balance into its own table. That was, the SELECT will not lock on the original table. Most of the running balance schemes that I have seen take a snapshot as of a given date (say, statement printing date) and record both the timestamp and the amount. Next month, you simply get last month's vaule and timestamp and query on transactions after that timestamp.
- Saish -
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
srinathHi 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. -
EJB Isolation levels in ejb-j2ee-engine.xml
Can anyone explain to me why I only seem to have the option of using the 'repeatable read' isolation level in Netweaver Developer Studio?
I'm new to SAP and Netweaver but as a seasoned J2EE developer I would have expected to find read committed, read uncommitted, serializable, as well as repeatable read.
Is there some SAP or Netweaver specific reason why I don't get to choose these options, or do I need to enable them by configuring properties somewhere?Hi Steve,
The reason is that the J2EE Engine EJB Container supports Read Committed and Repeatable Read isolation levels and Read Committed is the default one. That's why you only have the option of specifying Repeatable Read.
For more information on locking and isolation levels please have a look at these documents:
http://help.sap.com/saphelp_nw04/helpdata/en/37/019b3e25f95f14e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/a1/d81db94a10bc4b83b3f60b0e3037e7/frameset.htm
Best regards,
Vladimir -
Locking issues with transaction-isolation levels
I believe that my program is suffering from some sort of deadlock, and I was hoping
for some feedback.
I am helping to develop a trading system
using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
called LiveOrder that exposes several finder methods, most of which return java.util.Collections
of LiveOrder EJBs.
In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
isn't really supported by Oracle), in an effort to eliminate phantom reads, which
occur frequently if I do not use this isolation level. These finders all use transaction
attribute 'Required'.
It is my understanding that any transaction that calls any of these finders either
will lock the database if no other transaction already owns the lock, or will
wait until the lock is released if another transaction owns that lock. It also
is my understanding that a transaction that owns a lock will always release any
locks acquired upon expiration of that transaction (whether that be via commit
or via rollback).
However, this doesn't always appear the case: I have noticed occassionally that
several clients "hang," as they wait for the lock that, for some reason, is not
being released by its transaction. There do not appear to be any exceptions thrown
by the system prior to the system hanging, and the Weblogic administration tool
states that all transactions have been committed.
If it helps, I have included the general algorithm for the main (i.e., most expensive)
transaction:
1. a client calls a stateless session EJB's processOrder method (which should
implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
2. the transaction invokes the LiveOrder finder method (this should lock the DB,
so subsequent callers should block until the lock is released).
3. the transaction invokes another LiveOrder finder method, returning a separate
set of data.
4. the transaction invokes a finder method from a separate entity EJB (called
Security), which maps to a "read-only" table in the DB (default transaction-isolation
level, Required attribute).
5. the transaction invokes a finder method from yet another separate entity EJB
(called SecurityMarketValues), which maps to some other table (not read-only)
in the DB (again, default transaction-isolation level, Required attribute).
6. the transaction writes to the SecurityMarketValues entity EJB.
7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
8. the transaction ends by exiting method processOrder (thus releasing the locks
on the LiveOrder table in the DB).
In the system, there also exist other transactions that occassionally call the
LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
order table (i.e., these transactions do not make calls to other DB tables, and
close transactions almost immediately after starting them)
Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
ideas? I'm running out...
Jon,
If there was an Oracle deadlock the DB would resolve it momentarily and
will ultimately choose one transaction and throw an exception so it's
not a DB deadlock.
Take a thread dump at the very moment your system seems to be hanging
and look at what the threads are doing.
From your description it's not very unlikely that those threads of
yours that take snapshots of the data will not disrupt the transactions
so you may be surprised by the thread dumps that this is actually what
happens -- those snapshot thread wait for some lock while holding locks
needed by you other threads and it just slows down the system.
Regards,
Dejan
Jon Gadzik wrote:
>I believe that my program is suffering from some sort of deadlock, and I was hoping
>for some feedback.
>
>I am helping to develop a trading system
>using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
>called LiveOrder that exposes several finder methods, most of which return java.util.Collections
>of LiveOrder EJBs.
>
>In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
>finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
>isn't really supported by Oracle), in an effort to eliminate phantom reads, which
>occur frequently if I do not use this isolation level. These finders all use transaction
>attribute 'Required'.
>
>It is my understanding that any transaction that calls any of these finders either
>will lock the database if no other transaction already owns the lock, or will
>wait until the lock is released if another transaction owns that lock. It also
>is my understanding that a transaction that owns a lock will always release any
>locks acquired upon expiration of that transaction (whether that be via commit
>or via rollback).
>
>However, this doesn't always appear the case: I have noticed occassionally that
>several clients "hang," as they wait for the lock that, for some reason, is not
>being released by its transaction. There do not appear to be any exceptions thrown
>by the system prior to the system hanging, and the Weblogic administration tool
>states that all transactions have been committed.
>
>If it helps, I have included the general algorithm for the main (i.e., most expensive)
>transaction:
>
>1. a client calls a stateless session EJB's processOrder method (which should
>implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
>
>2. the transaction invokes the LiveOrder finder method (this should lock the DB,
>so subsequent callers should block until the lock is released).
>
>3. the transaction invokes another LiveOrder finder method, returning a separate
>set of data.
>
>4. the transaction invokes a finder method from a separate entity EJB (called
>Security), which maps to a "read-only" table in the DB (default transaction-isolation
>level, Required attribute).
>
>5. the transaction invokes a finder method from yet another separate entity EJB
>(called SecurityMarketValues), which maps to some other table (not read-only)
>in the DB (again, default transaction-isolation level, Required attribute).
>
>6. the transaction writes to the SecurityMarketValues entity EJB.
>
>7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
>
>8. the transaction ends by exiting method processOrder (thus releasing the locks
>on the LiveOrder table in the DB).
>
>
>In the system, there also exist other transactions that occassionally call the
>LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
>order table (i.e., these transactions do not make calls to other DB tables, and
>close transactions almost immediately after starting them)
>
>Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
>ideas? I'm running out...
>
>
>
>
-
A string of question about Locking & Isolation Level
Hi All
It is highly appreciated if someone give offer answers to my below questions
1) There are two ways of locking mechanism: Pessimistic & Optimistic. In general, do all J2EE app server support all these two ways of locking ?
2) It seems to me that setting the isolation level to "serialization" should result in using pessmistic locking. If no so, please point out my misconcept and explain to me.
3) Are there any differences in the way of entity bean programming as different locking mechansim is adopted ?
4) With regard to optimistic locking, will the app server throw out exception as data contention is detected ? Is the way of handling dependent on app server? Or It is transparent to the developer of entity bean. Please give me an e.g of j2ee app server product how to handle this scenario.
5) To adopt the approach of "optimistic" locking, do l have to implement it on my own using bean managed entity bean.
6) It seems to me that optimistic locking can achieve better concurrency. If it is inherently supported by app server for its container managed entity bean (=> totally transparent to the developer of entity bean). Is it always the rule of thumb to config the server to use "optimistic" locking instead of "pessimistic" ?
Sorry for bombarding you guys with such long list of questions. l would be very thankful if someone can help me consolidate my concept on these topics.
Also, please send your reply to [email protected] as well
thanks & regards
DannyHi Danny,
I became interested about the optimistic locking recently. If the topic is not long forgotten then this may make some difference!
We have attacked the optimistic locking issue by introducing audit fields (MODIFY_BY_USER, MODIFY_DATE) in tables where concurrency needs to be implemented.
We are retrieving rows from the table (for display or update) through Stateless Session Bean using simple SQL SELECT. The audit fields are fetched along with the business data and are kept at the client. While any of the concurrent users tries to update the row the audit fields are sent to the application server along with the modified business data. The relevant Entity Bean checks for any difference in the timestamp of the audit field (MODIFY_DATE) value with the value in the database. If a mismatch is found it reports a business exception to the user. Otherwise, the row is updated with the lastest timestamp value in the audit field MODIFY_DATE.
This works fine when two update operations are not concurrent, i.e., two users submit their update requests in a time lag greater than the time taken by the transaction to complete. This alone could not prevent the dirty update on the database.
Hence, to prevent any concurrent update contending for the same row you need to set the following ejbgen tag in the Entity Bean:
concurrency-strategy = Exclusive<<<<<Note: We are using Weblogic 6.1 with SP4 and CMP (no BMP).
Please let me know if you have got a better solution to tackle this issue.
Chandra. -
Hello,
I am still wrestlling a bit with the issues involved in setting an isolation
level. I am using WL 5.1, Oracle, and CMP.
I do now understand the issues involved between Oracle's
SERIALIZABLE and READ-COMMITTED isolation levels, etc.
But I also note that weblogic uses a pessimistic locking
approach for serializing access to entity ejb's. Doesn't this
locking supercede anything but an isolation level of
SERIALIZABLE? What happens with an isolation level
of READ-COMMITTED, even though the access to an
entity within any transaction will be serialized anyway?
Are there issues related to persistence issues outside of
ejb's, such as using JMS persistent messages within the
same system (same connection pool, etc.).
Also, I note that the ejb 2.0 spec in weblogic will allow
a more optimistic locking model. In this case, how will
multiple commits behave, will they behave according
to the isolation level chosen (READ-COMMITTED
or SERIALIZABLE?).
It's all confusing. What is the point, in ejb 1.1, for allowing
the bean developer to specify an isolation level, if all
access to entities will be done with exclusive locks?
What happens with multiple result finder methods? Does
this place exclusive locks on each entity found, within
a transaction?
Should I spend more time worrying about locking
models or isolation levels.
Am I just going around in circles?
Jason
Jason Rosenberg
SquareTrade
(remove 'nospam' from my return address)Well, for now, I am designing for Oracle. What do you mean
by hazy?
Kirk Wylie <[email protected]> wrote in message news:[email protected]...
Probably not something you can count on guaranteeing no blocking. The
database could very well block here, particularly if your'e using
anything other than Oracle on the back-end, and Oracle can be a bit,
ahem, hazy in its acceptance of its own semantics here.
Kirk Wylie
Jason Rosenberg wrote:
Well, if the database table is set up to use READ-COMMITTED,
then it shouldn't block on the database, correct?
Jason
Cameron Purdy <[email protected]> wrote in message news:[email protected]...
... which means it could block on the database, correct?
Cameron Purdy
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
A finder will never block on a container lock. For instance, imagine
that primary keys 3 and 4 are currently participating in a transaction
and are locked in server A. If a finder is called in server A which
returns these keys, the finder will run independently of the EJB server
locks. (Of course the database isolation will still apply.)
-- Rob
Jason Rosenberg wrote:
Ah, clustering saves the day!
I'm wondering though, since we don't have control over which
server in a cluster a given ejb may run on at any given time,
the concurrent behavior may be different to control. Some
times you can have concurrent access based on
READ-COMMITTED on the db level, and some times weblogic
will force a SERIALIZABLE behavior if 2 conflicting
ejb's get instantiated in the same container.
This is what I want. I would like complex finder methods
to be able to return a collection of primary keys over a
table, based on a READ-COMMITTED basis. This
needs to happen often, and shouldn't block (it's ok
if it misses out on uncommitted data in process, or
if it returns keys that may be in the process of being
deleted). But I don't ever want it to block because
another component has uncomitted changes in process.
Ideas? Wait for ejb2.0?
Jason
Rob Woollen <[email protected]> wrote in message
news:[email protected]...
It matters if you are in a cluster, or if othercomponents/applications
are accessing the same data.
It will also matter if your db does not have row-level locking.
-- Rob
Jason Rosenberg wrote:
I've excerpted below some of the text from the weblogic
documentation.
What this says to me is that, indeed, if an ejb entity is in anywayinvolved
in a transaction, all other transactions will be blocked frominstantiating
and using the bean instance until the transaction is over.
This is a de-facto SERIALIZABLE isolation level, is it not, with allthe
plusses and minuses. The plus is that data integrity is maintained,the
minus is that concurrent access is negatively effected.
What am I missing. Given this mechanism, what difference does it
make whether I use of a transaction isolation level ofREAD-COMMITTED
or SERIALIZABLE?
It looks like the story does change for ejb2.0.....
From the weblogic online documentation at:
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#108796
7
Locking Model for Entity EJBs
The EJB 1.1 container in WebLogic Server Version 5.1 uses apessimistic locking mechanism for entity EJB instances. As clients
enlist an EJB or EJB method in a transaction, WebLogic Server placesan exclusive lock on the EJB instance or method for the
duration of the transaction. Other clients requesting the same EJBor method block until the current transaction completes.
This method of locking provides reliable access to EJB data, andavoids unnecessary calls to ejbLoad() to refresh the EJB
instance's
persistent fields. However, in certain circumstances pessimistic
locking may not provide the best model for concurrent access to
the
EJB's data. Once a client has locked an EJB instance, other clients
are blocked from the EJB's data even if they intend only to
read
the persistent fields.
To improve concurrent access for entity EJB's, the WebLogic Server
EJB 2.0 container enables you to defer locking services to
the
underlying database. In most cases, the underlying data store can
provide finer granularity for locking EJB data, and improve
throughput for concurrent access to the bean's data. See EJB 2.0 forBEA WebLogic Server Overview for more information.
Cameron Purdy <[email protected]> wrote in message
news:[email protected]...
I believe the "locking" refers to an internal WL implementationthat
prevents multiple threads from accessing an EJB instance.
Cameron Purdy, LiveWater
"Jason Rosenberg" <[email protected]> wrote in message
news:[email protected]...
Hello,
I am still wrestlling a bit with the issues involved in setting
an
isolation
level. I am using WL 5.1, Oracle, and CMP.
I do now understand the issues involved between Oracle's
SERIALIZABLE and READ-COMMITTED isolation levels, etc.
But I also note that weblogic uses a pessimistic locking
approach for serializing access to entity ejb's. Doesn't this
locking supercede anything but an isolation level of
SERIALIZABLE? What happens with an isolation level
of READ-COMMITTED, even though the access to an
entity within any transaction will be serialized anyway?
Are there issues related to persistence issues outside of
ejb's, such as using JMS persistent messages within the
same system (same connection pool, etc.).
Also, I note that the ejb 2.0 spec in weblogic will allow
a more optimistic locking model. In this case, how will
multiple commits behave, will they behave according
to the isolation level chosen (READ-COMMITTED
or SERIALIZABLE?).
It's all confusing. What is the point, in ejb 1.1, for allowing
the bean developer to specify an isolation level, if all
access to entities will be done with exclusive locks?
What happens with multiple result finder methods? Does
this place exclusive locks on each entity found, within
a transaction?
Should I spend more time worrying about locking
models or isolation levels.
Am I just going around in circles?
Jason
Jason Rosenberg
SquareTrade
(remove 'nospam' from my return address)
Kirk Wylie | mailto:[email protected] | http://www.radik.com -
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) -
There appears to be an error when trying to view Health Reports from Central Administration. A simple fix within a SharePoint Stored Procedure fixes the problem. I get the error message "You can only specify the READPAST lock in the READ COMMITTED or
REPEATABLE READ isolation levels." when just trying to click "View Health Reports" --> Go in CA.
I have found the same problem in some blog posts which leads me to believe this is a bug:
Problems Viewing Health Reports in SharePoint 2013
From the blog post "I managed to work around it by altering the
proc_GetSlowestPages stored procedure and commenting out the
WITH (READPAST) line. "
This also worked for me. It would be great if a fix could be released for this problem as it seems to cause other problems as well (site analytics freezes).Hi Dennis
Hope you had found the hotfix and installed it.
For the benefit of others who visit this thread SharePoint Server 2013 Client Components SDK hotfix package addresses this issue.http://support.microsoft.com/kb/2849962
Regards
Sriram.V -
Pessimistic Locking mechanism in SAP Gateway.
Hi All,
I am new to SAP Gateway. I know there are two types of locking mechanism ( optimistic and pessimistic) . Optimistic we do by etag and if-match.
Is there any idea of how to do by pessimistic approach.
For example we are reading a contract and then updating it. So, in get_entity we have to put the lock while reading and we have to unlock while updating. But how does it works. Whether the lock automatically get released after the get_entity method.
Kindly guide me in proceeding further.Hi Sundar,
Here is my opinion :
Gateway is Completely Stateless till the current version which is SP8. So Pessimistic Locking would not be available out of the box by Gateway. You need to implement your custom logic to achieve this behaviour. However simulating a Pessimistic Lock in a complete stateless architecture will lead to many complexities which often might lead to inconsistency in the Application. As mentioned by Krishna, you can store lock information in some table in backend , but it might get messy very easily. I would not recommend to do so. However if you are really keen to do Pessimistic Locking kind of mechanism, what about the following approach -----
1. In the OData service, let us have an extra Entity called LOCK which has properties such as USER, RESOURCE_ID(such as contract ID),DATE,TIME. USER and RESOURCE_ID is the key in this entity. This data is stored in a table in database.
2. When a particular USER opens the CONTRACT screen in EDIT mode, the UI fires a POST(Create) call for Entity LOCK with the USER and RESOURCE_ID(contract ID in this case). In the backend database table if no entry exists with that USER ID and RESOURCE_ID, then a new entry is created and the USER is allowed to EDIT the contract. If an entry already exist in table then it means some other user is already in Edit mode , and the current user is refused to access the resource in edit mode.
3. When the USER saves the CONTRACT you need to fire a DELETE request for that Particular LOCK entity. Thus is resource is dequeued.
However this is like a vanilla flow. Handling can be complicated if user closes the browser, disconnects the network connection, opens parallel session etc etc.
Rather a clean approach would be an Optimistic lock. Fiori Applications are using this mechanism to handle concurrency control. You may refer to my reply on Locking mechanism in SAP Gateway. for a little more information on Optimistic Locking.
I agree that even though Optimistic locking works pretty well in REST based applications as it allows operations to be free from overhead of long transaction , there can be situations as mentioned below, where an Optimistic lock might not be preferred -
1. Where the chances of concurrency collision is very high (Example: Online Reservation of Tickets)
2. If modifying the resource by the user requires a lot of typing (However JS libraries such as Garlic.js, sisyphus.js or HTML5 Local storage can help us here )
Now it is upto you to decide upon the approach .. -
You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels
Hi, I have a piece of code that works fine in SSMS as T-SQL. When I put the T-Sql inside a SP, I get the error :
You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels
The script starts is as follows (only select)
SET NOCOUNT ON
Set Transaction Isolation Level Read Committed
Set Deadlock_Priority Low
Select......
From MyTable WITH (NOLOCK)
GROUP BY .....
Order BY ....
works fine as I said in SSMS as T-SQL but the SP generates the following
Msg 650, Level 16, State 1, Procedure usp_TotalMessages, Line 15
You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels.
By the way, when it says line 15, from where we should start counting, is it from The USE DB statement which includes comments as well as Set ANSI....or should we start counting from the Alter PRocedure statement
Thanks in advanceSet Transaction Isolation Level Read Committed
Set Deadlock_Priority Low
Select......
From MyTable WITH (NOLOCK)
GROUP BY .....
Order BY ....
First you define transactionlevel = "Read Committed", then you use a query hint "NOLOCK" which is equivalent to "Read Uncommitted"; so what do you want now, committed or uncommitted, you have to decide.
Olaf Helper
[ Blog] [ Xing] [ MVP] -
Isolation Level problems with DDConverter , wl4.51 (EJB spec 1.0) to wl5.1 (EJB spec 1.1)
Hi ,
I was using the DDConvertor supplied with WL51 to convert my old
DeploymentDescriptor.txt to the new XML format.
I have noticed that the Isolation Level did not pass to the new format.
My entity bean is not container managed and the Isolation level is
READ_COMMITED .
No weblogic-cmp-rdbms-jar.xml File was generated.
Attached are the files.
Could you please tell me where can I specify the Isolation Level if I have
no rdbms file ?
thanks
Amit Sivan
[DeploymentDescriptor.txt]
[weblogic-ejb-jar.xml]weblogic-ejb-jar.xml
amit sivan wrote:
Hi ,
I was using the DDConvertor supplied with WL51 to convert my old
DeploymentDescriptor.txt to the new XML format.
I have noticed that the Isolation Level did not pass to the new format.
My entity bean is not container managed and the Isolation level is
READ_COMMITED .
No weblogic-cmp-rdbms-jar.xml File was generated.
Attached are the files.
Could you please tell me where can I specify the Isolation Level if I have
no rdbms file ?
thanks
Amit Sivan
; Copyright (c) 1998-1999 by BEA WebXpress. All Rights Reserved.
(EntityDescriptor
beanHomeName pay2card.OnlineHomeEntity
enterpriseBeanClassName pay2card.beans.online.entity.OnlineEntityBean
homeInterfaceClassName pay2card.beans.online.entity.OnlineEntityHome
remoteInterfaceClassName pay2card.beans.online.entity.OnlineEntity
isReentrant false
(accessControlEntries
; DEFAULT [admin manager]
); end accessControlEntries
(controlDescriptors
(DEFAULT
isolationLevel TRANSACTION_READ_COMMITTED
transactionAttribute TX_REQUIRED
runAsMode CLIENT_IDENTITY
; runAsIdentity admin
); end DEFAULT
); end controlDescriptors
(environmentProperties
; homeClassName
; ejbObjectClassName
maxBeansInFreePool 20
maxBeansInCache 1000
idleTimeoutSeconds 60
; isModifiedMethodName isModified
); end environmentProperties
; Entity EJBean-specific properties:
primaryKeyClassName pay2card.beans.online.entity.OnlinePK
; end entity EJBean-specific properties.
); end EntityDescriptor
<?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>pay2card.OnlineHomeEntity</ejb-name>
<caching-descriptor>
<max-beans-in-free-pool>20</max-beans-in-free-pool>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-seconds>
</caching-descriptor>
<persistence-descriptor>
<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>
</persistence-descriptor>
<jndi-name>pay2card.OnlineHomeEntity</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar> -
Restore default isolation level fails with connection in pool
Hi,
I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
It has to be possible to change the isolation level for transaction, isn´t it?
Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
ConnectionManager connectionManager = new ConnectionManager();
Connection con = null;
int transactionIsolationLevel = 0;
Queue queue = null;
List list = null;
try {
con = connectionManager.getConnection();
transactionIsolationLevel = con.getTransactionIsolation();
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
// auskommentiert für RE
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
con.setAutoCommit( false );
QueueManager queueManager = new QueueManager();
list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
con.commit();
} catch (ClassNotFoundException cnfe) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
handleExceptions(queue, cnfe);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (SQLException sqle) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
handleExceptions(queue, sqle);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (QueueManagerException qme) {
logger.error(LOGLOC + "Exception executing queue manager!", qme);
handleExceptions(queue, qme);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} finally {
try {
con.setAutoCommit(true);
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
// Auskommentiert für RE
con.setTransactionIsolation( transactionIsolationLevel );
con.close();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);
The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
Any hints, solutions?Hi,
I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
It has to be possible to change the isolation level for transaction, isn´t it?
Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
ConnectionManager connectionManager = new ConnectionManager();
Connection con = null;
int transactionIsolationLevel = 0;
Queue queue = null;
List list = null;
try {
con = connectionManager.getConnection();
transactionIsolationLevel = con.getTransactionIsolation();
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
// auskommentiert für RE
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
con.setAutoCommit( false );
QueueManager queueManager = new QueueManager();
list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
con.commit();
} catch (ClassNotFoundException cnfe) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
handleExceptions(queue, cnfe);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (SQLException sqle) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
handleExceptions(queue, sqle);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} catch (QueueManagerException qme) {
logger.error(LOGLOC + "Exception executing queue manager!", qme);
handleExceptions(queue, qme);
try {
con.rollback();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception rolling back transaction!", e);
} finally {
try {
con.setAutoCommit(true);
if( logger.isInfoEnabled())
logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
// Auskommentiert für RE
con.setTransactionIsolation( transactionIsolationLevel );
con.close();
} catch (SQLException e) {
logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);
The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
Any hints, solutions?
Maybe you are looking for
-
IDOC to FTP File - Error : SAP:Stack No receiver agreement found for send
Hello Friends, I need to configure a senario Idoc to FTP File, Í did required settings in R3 and in PI... , did mapping and configuratino in PI... and when I send my idoc I got error msg in monitor <SAP:Stack>No receiver agreement found for sender ,B
-
Applications option is missing from workspace
Hi Friends, Applications option is missing from workspacee. Please help me to resolve it. Thanks in Advance
-
What r the new chages in strus1.2
what r the new chages in strus1.2 compare to struts 1.2
-
I can't restore an App on my new iPad
I purchased an app a while back. Now I got a new iPad mini and when I downloaded the app on the new iPad ( with same Apple ID), only part of the app is available; the other levels are locked and available for upgrade at an additional charge. But th
-
Hola amigos, tengo un Iphone 5s, cuenta con el software iOS 8.0.2 actualizado y SIRI NO me escucha de manera normal por el micrófono, este necesita manos libres o audífonos, en Ajustes, general, SIRI, esta activado así como Permitir "Oye Siri", adici