Transactions and database locks

Hi,
               We use Weblogic 4.5.1 on Windows NT 4.0 with Oracle 8.0.5. Our database
          isolation is set to TRANSACTION_READ_COMMITTED. I have an entity bean with
          TX_REQUIRED & TRANSACTION_READ_COMMITTED settings. If my client creates a
          transaction, and starts calling methods on this entity bean, is the
          corresponding database row locked for the duration of the transaction? We
          have concurrent SQl-plus sessions going on and we want make sure there is
          no data corruption. If the row is not locked, is it ok for me to explicitly
          lock it from inside my entity bean?
          Thanks,
          Srini.

Hi. This should have been posted to the EJB or JDBC group, but I'll take it.
          This is an Oracle question. If you have a transaction as you've described,
          then the behavior will be exactly as if you had multiple SQL-PLUS sessions,
          and in one of them, you did:
          SQL> BEGIN;
          -- do what your bean would do;
          SQL> COMMIT;
          You can test this there. In general, you'll find that Oracle's optimistic locking
          will allow any number of simutaneous transactions to access a given row
          at one time. Oracle does not lock the real data while a transaction is ongoing,
          instead making a copy for the client to work off of. At commit time, depending
          on the isolation level semantics, some or all of the transactions may fail when
          Oracle tries to update the real data from the per-session private data.
          I would council against running with SERIALIZABLE mode because there
          is a serious bug in Oracle, where serializable transactions may fail silently.
          Details on request.
          Joe
          Srini wrote:
          > Hi,
          > We use Weblogic 4.5.1 on Windows NT 4.0 with Oracle 8.0.5. Our database
          > isolation is set to TRANSACTION_READ_COMMITTED. I have an entity bean with
          > TX_REQUIRED & TRANSACTION_READ_COMMITTED settings. If my client creates a
          > transaction, and starts calling methods on this entity bean, is the
          > corresponding database row locked for the duration of the transaction? We
          > have concurrent SQl-plus sessions going on and we want make sure there is
          > no data corruption. If the row is not locked, is it ok for me to explicitly
          > lock it from inside my entity bean?
          >
          > Thanks,
          > Srini.
          PS: Folks: BEA WebLogic is in S.F., and now has some entry-level positions for
          people who want to work with Java and E-Commerce infrastructure products. Send
          resumes to [email protected]
          The Weblogic Application Server from BEA
          JavaWorld Editor's Choice Award: Best Web Application Server
          Java Developer's Journal Editor's Choice Award: Best Web Application Server
          Crossroads A-List Award: Rapid Application Development Tools for Java
          Intelligent Enterprise RealWare: Best Application Using a Component Architecture
          http://weblogic.beasys.com/press/awards/index.htm

Similar Messages

Re: what is difference between sap locking and database locking

hi,
    what is difference between sap locking and database locking. Iam locked the table mara by using lock objects.
But iam unable to unlock the mara table. I give u the coding. Please check it.
REPORT zlock .
CALL FUNCTION 'ENQUEUE_EZTEST3'
EXPORTING
   MODE_MARA            = 'S'
   MANDT                = SY-MANDT
   MATNR                = 'SOU-1'.
call transaction 'MM02'.
CALL FUNCTION 'DEQUEUE_EZTEST3'
     EXPORTING
          mode_mara = 'E'
          mandt     = sy-mandt
          matnr     = 'SOU-1'.
IF sy-subrc = 0.
WRITE: 'IT IS unlocked'.
ENDIF.

Hi Paluri
Here is the difference between SAP locks and Database locks, i will try to find the solution to your code.
Regards
Ashish
Database Locks: The database system automatically sets database locks when it receives change statements (INSERT, UPDATE, MODIFY, DELETE) from a program. Database locks are physical locks on the database entries affected by these statements. You can only set a lock for an existing database entry, since the lock mechanism uses a lock flag in the entry. These flags are automatically deleted in each database commit. This means that database locks can never be set for longer than a single database LUW; in other words, a single dialog step in an R/3 application program.
Physical locks in the database system are therefore insufficient for the requirements of an R/3 transaction. Locks in the R/3 System must remain set for the duration of a whole SAP LUW, that is, over several dialog steps. They must also be capable of being handled by different work processes and even different application servers. Consequently, each lock must apply on all servers in that R/3 System.
SAP Locks:
To complement the SAP LUW concept, in which bundled database changes are made in a single database LUW, the R/3 System also contains a lock mechanism, fully independent of database locks, that allows you to set a lock that spans several dialog steps. These locks are known as SAP locks.
The SAP lock concept is based on lock objects. Lock objects allow you to set an SAP lock for an entire application object. An application object consists of one or more entries in a database table, or entries from more than one database table that are linked using foreign key relationships.
Before you can set an SAP lock in an ABAP program, you must first create a lock object in the ABAP Dictionary.

UPDATE statement and database locks

Hello everybody,
I have a problem related to an UPDATE statement. There are two applications, let say A and B.
Application A executes:
update some_table
set some_field = 'value_A',
where pk_field=1
no commit!
Application B executes:
update some_table
set some_field = 'value_B',
where pk_field=1
Now application B is locked and wait until application A executes a commit.
THIS IS A PROBLEM!
I know one way to solve this problem:
Both applications should execute "select for update nowait" before
updating a row.
Is there any other solutions? Something like "update nowait"?
thanks in advance
Dmitri Geller
DGeller (at) lhsgroup dot com

The major difference between my approach and standard "select for update nowait + update"
approach, is more information for user : who blocked his object, and when. Else , i don't see the
differences. Yep. And a Boieng 747 and bicycle is not much a difference as both are used for transporting people.
Are you against select + nowait ?No, I am for understanding transaction isolation, serialisation, ACID principles, the differences between optimistic and pessimitic locking and so on
You wrote "THE LOCK is good". OK, and what about time ?The two has NOTHING to do with one another. Not a single thing.
In real industrial systems the users cannot wait more then few seconds. But the transactions can
run much more. It isn't acceptable.If by implication you mean that I'm in the .edu environment that does not deal with "real corporate systems", I'm not.
I recently wrote a special replicator in PL/SQL. It makes extensive use of customised parallel processing (does not use PQ as it also support Oracle SE). It hits very busy tables (with far over a 1000 rows/sec transaction rate). I did not have to hack my own form of locking. Performance is excellent.
Why? Not because I am a brilliant Linus-like programming genius. Simply because I used Oracle as it has been designed to use.
Can you claim the same? Can you show me the Oracle reference material that states that you need to write your own Lock Manager? Can you show me expert opinion from recognised inviduals such as Tom Kyte, Jonathan Lewis, Gary Milsap and others that state that Oracle's concurrency controls need to be hacked like you did in order to make it work?
Can you provide me with any sound technical evidence to backup your claims that your method is better than what Oracle has built into the core of the database?

Question on autcommit of transaction and database configuration

I have a ase 12.5 with following setting on a dev server:
select into/bulkcopy/pllsort : true
ddl in tran: true
when run a pb app without autocommit setting. It is fine.
but on my production server, same db have different option setting:
select into/bulkcopy/pllsort : false
ddl in tran: false
then run same app, the transaction from pb app not commit, cause lot of lock and crash app.
So what the relationship between pb transaction autocommit attribute and sybase ase database dboptions setting?

Hi Kent;
FWIW: Check the "locking scheme) in development vs production. You may have page level in one DB vs row locking enabled in the other environment. This can make a world of difference in the locking conflicts when you run your PB application.
Regards ... Chris

Autonomous Transactions and table locks

Does a commit statement in an Autonomous Transaction block in PL/SQL release locks aquired in the master transaction block?
e.g
CREATE OR REPLACE PACKAGE test_auto_trans AS
PROCEDURE mainproc;
PROCEDURE testproc;
END test_auto_trans;
CREATE OR REPLACE PACKAGE BODY test_auto_trans AS
/*****************Main Procedure*********************/
PROCEDURE mainproc AS
BEGIN
LOCK TABLE a,b,c IN EXCLUSIVE MODE nowait;
/*some processing involving tables a,b,c here. no commit done yet*/
testproc();
/* will the locks on a,b,c still be available here? */
EXCEPTION
WHEN others THEN
dbms_output.put_line('Error');
dbms_output.put_line(sqlcode);
dbms_output.put_line(sqlerrm);
RAISE;
END mainproc;
/*****************test Procedure*********************/
PROCEDURE testproc AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
/*some processing using tables a,b,c here*/
commit;
EXCEPTION
WHEN others THEN
dbms_output.put_line('Error');
dbms_output.put_line(sqlcode);
dbms_output.put_line(sqlerrm);
RAISE;
END testproc;
END test_auto_trans;
/

No transaction will release the locks held by another transaction. When you declare a stored proc to be PRAGMA AUTONOMOUS_TRANSACTION, it is essentially the same as if you logged in as the same user but in a different session.
For example, if I have two sqlplus sessions running as user a, if I do an update in session1 and a delete and commit in session 2 I can still rollback in session 1.
However, your psuedo code as posted will not work at all since the call to test_proc will block until you commit in the main proc, and since test_proc will never return, the main proc will never get to commit. It is exactly analogous to the following:
session1> SELECT * FROM t;
        ID DESCR
         1 One
         2 Two
session1> LOCK TABLE t IN EXCLUSIVE MODE nowait;
Table(s) Locked.
session1> UPDATE t SET descr = 'Un'
2 WHERE id = 1;
1 row updated.so far, this is your main proc. Now, in another session (which is equivalent to your autonomous transaction procedure), I do:
session2> UPDATE t SET descr = 'Deux'
2 WHERE id = 2;which as I type is still waiting on the commit from session 1. Therefore, I cannot get to commit the autonomous transaction which would return control to session1
HTH
John
Message was edited by:
John Spencer
Sorry, I initially forgot to answer your actual question "what about DML statements like truncate". Since TRUNCATE is actually a DDL statement I will assume that is what you meant. My initial answer covers DML statements (except SELECT which will work).
All DDL statements in Oracle go
COMMIT
DDL statement
COMMIT
since the initial commit requires a very brief exclusive lock, you will get an error like:
ORA-00054: resource busy and acquire with NOWAIT specified
Exactly as if you did:
session1> LOCK TABLE t IN EXCLUSIVE MODE nowait;
Table(s) Locked.then tried to do it again the another session
session2> LOCK TABLE t IN EXCLUSIVE MODE nowait;
LOCK TABLE t IN EXCLUSIVE MODE nowait
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

Re: Transactions and Locking Rows for Update

Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - Calvin

We have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]>

Transactions and Locking Rows for Update

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

ADF Database lock and Refresh

I have two issues regarding ADF.
Database lock :
The problem :
In most test-cases the database lock functionality is working correctly in my app. We have two users working on the same dataset trying to store at the same time, one user get to store, and the other get a message saying that the rowkey have been changed, and can after s short while store his data.
However, in one .jsp saving at the same time gives a lock lasting for 15-20 minutes. The ViewObject related to this .jsp have many EntityObjects (6 EntityObject in one Viewobject), so it is more complex than the others.
What we have tried :
Changing the jbo.locking.mode to optimistic on the Appmodule.
What more can we do in ADF for configuring the locking? Is there a way to trace to see what is creating the lock for 15 - 20 minutes?
Refresh :
The problem :
In most cases ADF handles refresh of data correctly. But some places it seems to not update correctly. We are using JSF (ADF Faces)
What we have tried :
Changing the refresh condition on the iterator in the pageDef.xml to always.
<iterator id="berpriListIterator" RangeSize="-1"
binds="berpriList" Datacontrol="RegServiceDataControl1"
CachResult="false"
Refresh="always" />
Adding InvokeAction :
<invokeAction Binds="Execute" id="invokeExecute" RefreshCondition="${adfFacesContext.postback ==false }" />
Editing the Action:
<action IterBinding ="berpriListIterator" id="Execute" Instance=" " Datacontrol="" RequiresUpdateModel="true" Action="2" />
This seems to work. Is this a bug in ADF or should we always add invokeAction on all pageDefs? Some places it seems to update correctly even without invokeAction.
Is this issue also in 11g?

Using jbo.locking.mode=optimistic I would never expect an ADF web application to hold only any database locks for longer than the span of the commit processing in the normal case. The locks would be attempted only during the commit processing and if any DML error (including a failed lock attempt) occurs, then the transaction should be rolled back to a SAVEPOINT that ADF acquires before beginning the commit processing.
One way an ADF application could acquire and retain locks would be if your application is using the Transaction.postChanges() method to explicitly post, but not commit, pending database changes. Are you doing that by chance?
There are occasions in the Oracle database when doing one operation like a delete or update can lock a table if you have unindexed foreign keys (see http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:292016138754 ). Not sure if that is your situation, but still the locks should only be around for the very short span of time during the commit processing.
Regarding the refresh, you should be able to verify by launching two separate instances of the ADF Business Components Browser testing tool that, when you do the following:
(Assuming app module has jbo.locking.mode=optimistic)
* User A queries Employee with Empno = 7839
* User B queries Employee with Empno = 7839
* User A modifies Sal attribute from 5000 to 4999, Comm attribute from NULL to 1 and commits
* User B modifies Comm attribute from NULL to 55 and commits
* User B receives the "RowInconsistentException"
And, you should see:
* Modified value of Comm in User B's Emp row stays at its modified value (as would any attributes that are modified in its current transaction)
* Any unmodified values (like User B's Emp row's Sal value) will be refreshed to the current state of the database, so it should now be 4999
If you are using JSF and partial submits, you might need to configure PPR to see these data changes reflected accurately in the JSF page.

Different between database lock and sap lock

Hi All,
What is different between database lock and sap lock why sap introduced locking mechanism.
Thanks
Santosh

From a database perspective, every dialog step forms a physical and logical unit:
the database transaction.. The database lock administration can only coordinate
this type of database transaction. From an SAP point of view, however, this is
not sufficient, because SAP transactions, which are formed from a sequence of
logically related work steps that are consistent in business terms, are generally
made up of several dialog steps. SAP systems need to have their own lock
management. This is implemented using the enqueue work process. This also
ensures that the platform-independence of the lock management is maintained.

Database locking using JSP and Oracle database

Dear All
I am reading about how to do database locking in general and i want to implement these mechanisms using JSP pages and oracle database, but i have the following questions:-
1.If i write a “select for update” quesry in the JSP page will it locks the record ? or it will not lock the record because the connection between the JSP pages and the server will be stateless in most online systems?
2.If i write all my jave code in transaction , something like this:-
• Begin transaction
• Commit or
• Rollback
Then should i be worried about the locking issues or the database manger will handle the locking mechanisms to insure data integrity(and what the default mechanism (if any) that the oracle database manger use to do the locking)?
3. If the answer for question 2 is no, then how can i handle the optimistic and the pentemistic locking using JSP pages?
BR

One way to solve this issue is as follows:
* You add a new column to each database table called 'version' which is of int type.
* Each time you alter any field in a record, you increament the version number.
* When you read a record and display it, you store the version number in your code
* when you go to update the record, you write your sql something like this:
update person set firstName=? where personId=? and version=?
Where the version is whatever you stored locally. If someone altered the record in the database while your
end user was looking at it, the version numbers will not match and the sql statement will
return zero as the number of records it altered. If its zero, inform the end user someone altered the record
while he was looking at it and weather or not he wants to proceed.
The chances of two people altering the same record in a table while both are logged in and viewing the same set of data is small so such collisions will be few.
You only need transactions if you are updating more than one record at a time (in the same table or multiple tables).
You dont need it for reading records if you use a single sql statement to read (for example: to join multiple tables).
In general, you get a (pooled) connection, use it, and close it as quickly as possible in a try/catch/finally block. You dont hold onto it for the duration of the user's session. A book on JDBC should help clarify this.

Database locking (state versus stateless) and indexes on oracle database

Does anyone have a link to a document talking about database locking (state versus stateless) and talking about indexes in oracle database?

No version information and no information as to what you mean by "locking" so no help is possible.
You could mean LOCK TABLE in version 7.3.4 or SELECT FOR UPDATE in 11.1.0.7 or something else entirely.

How to manage and prevent database lock for database admin and development

how to manage and prevent database lock for database admin and development
[email protected]

Hi,
can someone advise me some good book or even better a PDF or a white paper on the Web where it's explained well how to design and manage a relational database (that is normal forms, tuning, design, implemantation...)?
I've been working on Oracle databases for a few years as pl sql programmer, but I'd like to read something describing well the relational database theory, because I've been asked to work as database designer.There are many books available in the market, please go through this link -- http://www.amazon.com/gp/bestsellers/books/549646/ref=pd_ts_b_nav
I've been told to read "Fundamentals of Database Systems" by Ramez Elmasri, but I ask here for some more advices.I would strongly recommend reading this book, it was my best reference during my college study and even after starting my DBA career.
Thanks,
Hussein

Database locks in OBPM 10gR3

Environment:
Oracle BPM 10gR3 Version: 10.3.1.0.0 Build: #99954
WebLogic Server 10.0 MP1 Clustered domain
JDBC Driver - WebLogic Type 4 XA ( weblogic.jdbcx.oracle.OracleDataSource )
We have a BPM project deployed on the WLS 10.0 MP1 Cluster,which was running fine for the last 18 months. But all of a sudden we are experiencing the database locks errors for the last few days, when we try to restart the BPM Engine.
WebLogic JTA Timeout = 30 seconds
Database Distributed_Lock_Timeout = 60 seconds
WebLogic Datasources for Directory and Engine XA Connection Timeout = 30 seconds
Error
Process '/Test#Default-1.0' could not be started. Details:\nProcess execution engine execution error.
Caused by: Exception [java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock ].
Caused by: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
fuego.papi.impl.EngineExecutionException: Process execution engine execution error.
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:139)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:79)
     at fuego.server.execution.DefaultEngineExecution.executeWithoutComponentImmediate(DefaultEngineExecution.java:185)
     at fuego.server.execution.EngineExecution.executeWithoutComponentImmediate(EngineExecution.java:86)
     at fuego.ejbengine.service.EJBActiveProcessService.startProcess(EJBActiveProcessService.java:92)
     at fuego.server.service.ActiveProcessService.runProcessesLoader(ActiveProcessService.java:118)
     at fuego.server.service.ActiveProcessService.activateProcesses(ActiveProcessService.java:88)
     at fuego.ejbengine.service.EJBActiveProcessService.doActivateProcesses(EJBActiveProcessService.java:63)
     at fuego.ejbengine.cluster.DistributedEJBActiveProcessService.initialize(DistributedEJBActiveProcessService.java:37)
     at fuego.ejbengine.cluster.ClusterObjectFactory.initializeActiveProcessService(ClusterObjectFactory.java:33)
     at fuego.ejbengine.Engine.startServices(Engine.java:448)
     at fuego.ejbengine.Engine.start(Engine.java:129)
     at fuego.ejbengine.servlet.AbstractSchedulerServlet.init(AbstractSchedulerServlet.java:91)
     at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:282)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
     at weblogic.security.service.SecurityManager.runAs(Unknown Source)
     at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:63)
     at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
     at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
     at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:507)
     at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1853)
     at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1830)
     at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1750)
     at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2909)
     at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:973)
     at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:361)
     at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
     at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
     at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
     at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
     at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
     at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
     at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
     at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
     at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
     at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
     at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
     at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:182)
     at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:359)
     at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
     at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:196)
     at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
     at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
     at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
     at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
     at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
     at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
Caused by: fuego.directory.DirectoryRuntimeException: Exception [java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock ].
     at fuego.directory.DirectoryRuntimeException.wrapException(DirectoryRuntimeException.java:85)
     at fuego.directory.provider.jdbc.oracle.OraclePersistenceManager.mapSQLException(OraclePersistenceManager.java:183)
     at fuego.directory.provider.jdbc.datadirect.oracle.DataDirectOraclePersistenceManager.mapSQLException(DataDirectOraclePersistenceManager.java:50)
     at fuego.directory.provider.jdbc.JDBCServiceAccessor.mapSQLException(JDBCServiceAccessor.java:78)
     at fuego.directory.provider.jdbc.JDBCProcessAccessor.updateDeployedProcess(JDBCProcessAccessor.java:1330)
     at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at fuego.directory.provider.DirectorySessionImpl$AccessorProxy.invoke(DirectorySessionImpl.java:756)
     at $Proxy57.updateDeployedProcess(Unknown Source)
     at fuego.directory.DirDeployedProcess.update(DirDeployedProcess.java:1022)
     at fuego.server.ActiveProcessManager.handleProcess(ActiveProcessManager.java:496)
     at fuego.server.service.ActiveProcessService.startProcess(ActiveProcessService.java:136)
     at fuego.ejbengine.service.EJBActiveProcessService.startProcessImpl(EJBActiveProcessService.java:107)
     at fuego.ejbengine.service.EJBActiveProcessService.access$100(EJBActiveProcessService.java:32)
     at fuego.ejbengine.service.EJBActiveProcessService$2.execute(EJBActiveProcessService.java:95)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startBaseTransaction(TransactionAction.java:470)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:551)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:212)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:123)
     ... 52 more
Caused by: java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
     at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source)
     at weblogic.jdbc.base.BaseExceptions.getException(Unknown Source)
     at weblogic.jdbc.oracle.OracleImplStatement.execute(Unknown Source)
     at weblogic.jdbc.base.BaseStatement.commonExecute(Unknown Source)
     at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source)
     at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source)
     at weblogic.jdbcx.base.BasePreparedStatementWrapper.executeUpdate(Unknown Source)
     at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:125)
     at fuego.jdbc.FaultTolerantPreparedStatement.executeUpdate(FaultTolerantPreparedStatement.java:623)
     at fuego.directory.provider.jdbc.JDBCPersistenceManager.update(JDBCPersistenceManager.java:946)
     at fuego.directory.provider.jdbc.JDBCProcessAccessor.updateDeployedProcess(JDBCProcessAccessor.java:1327)
     ... 68 more

Hello -
Following is the Oracle recommendation for BPM timeouts. Now you can try this.
Increase the timeout:
-in the Oracle Weblogic console go to Services -> JTA -> Timeout Seconds . Set the value to 300.
also the DISTRIBUTED_LOCK_TIMEOUT value for BPM should follow the following formula:
DISTRIBUTED_LOCK_TIMEOUT >= XA Transaction Timeout >= WebLogic Server JTA timeout
This means that the configured "DISTRIBUTED_LOCK_TIMEOUT" value should be equal to or
larger than the "XA Transaction Timeout" value which in turn should be equal to or larger than the "WebLogic Server JTA timeout".
Note : Check your previous BPM Engine logs, you can see the timeout warning.
BR,
Justin.

ORA-02049: timeout: distributed transaction waiting for lock

Hi,
My name is Guneet and I'm working on an application running on BEA Weblogic Server 9.2 running on a Red Hat Linux box using Oracle 10g as the database. My problem is that recently our code started getting the following exception while updating a database table.
java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
Application Details
* Using Stateless Session EJB
* Only one Business method in this EJB with transaction attribute set to "required"
* This method executes two select queries & one update query
* We are using JDBC to access the database.
* We have configured a Data Source & are using it to get a database connection.
* Weblogic's Oracle Driver is being used.
More details
* The application has been running well since a month.
* Two days ago,the update query failed with the above error.
* At that time, a single client was accessing the system.
* Once this problem occurs, it starts appearing frequently.
* Eventually a request to get a connection from the Data Source times out & the exception copied at the end is thrown
* At this stage the application gets stuck and all requests trying to get a connection end up with this exception.
* Fortunately, Restarting the Weblogic Server gets us out of this problem and transactions resume normally.
Now my questions are
# Why is this error happening & what does it mean?
# It looks like the second exception (unable to get a connection from ds) is an after effect of the first problem (ORA-02049) once it appears for a couple of times. Can somebody validate this?
# Though I don't understand JTA well but I don't think this application needs distributed transactions so, I'm thinking of modifying the driver type to non-XA oracle driver. Any advise/pointers/comments on this front is welcome !!!!!!!!
Thanks
Guneet Sahai
Exception Trace
Dec 27, 2006 4:47:50 PM | com.gisil.themis.db | SEVERE | Unable to load merchant DEL = 911168900164. Reason - java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_RMERR start() failed on resource 'themis-ds': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException: Unexpected error during start for XAResource 'themis-ds': Transaction timed out after 29 seconds
BEA1-252DE51AC930078CA638
at weblogic.jdbc.wrapper.XA.createException(XA.java:103)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:753)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1182)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1115)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:274)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:497)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:429)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1408)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1413)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

guneet sahai wrote:
Hi,
My name is Guneet and I'm working on an application running on BEA Weblogic Server 9.2 running on a Red Hat Linux box using Oracle 10g as the database. My problem is that recently our code started getting the following exception while updating a database table.
java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
Application Details
* Using Stateless Session EJB
* Only one Business method in this EJB with transaction attribute set to "required"
* This method executes two select queries & one update query
* We are using JDBC to access the database.
* We have configured a Data Source & are using it to get a database connection.
* Weblogic's Oracle Driver is being used.
More details
* The application has been running well since a month.
* Two days ago,the update query failed with the above error.
* At that time, a single client was accessing the system.
* Once this problem occurs, it starts appearing frequently.
* Eventually a request to get a connection from the Data Source times out & the exception copied at the end is thrown
* At this stage the application gets stuck and all requests trying to get a connection end up with this exception.
* Fortunately, Restarting the Weblogic Server gets us out of this problem and transactions resume normally.
Now my questions are
# Why is this error happening & what does it mean?
# It looks like the second exception (unable to get a connection from ds) is an after effect of the first problem (ORA-02049) once it appears for a couple of times. Can somebody validate this?
# Though I don't understand JTA well but I don't think this application needs distributed transactions so, I'm thinking of modifying the driver type to non-XA oracle driver. Any advise/pointers/comments on this front is welcome !!!!!!!!
Thanks
Guneet SahaiHi Guneet. If you want to debug the JTA issue, I suggest opening an official
support case. They will lead you through producing the JTA debug information.
However, I believe you are correct that the transaction you describe is
completely doable with a simple local transaction, so if you were to alter
your pool to use the non-XA driver, it would probably be faster, simpler,
and just work.
Let me know...
Joe
>
Exception Trace
Dec 27, 2006 4:47:50 PM | com.gisil.themis.db | SEVERE | Unable to load merchant DEL = 911168900164. Reason - java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_RMERR start() failed on resource 'themis-ds': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException: Unexpected error during start for XAResource 'themis-ds': Transaction timed out after 29 seconds
BEA1-252DE51AC930078CA638
at weblogic.jdbc.wrapper.XA.createException(XA.java:103)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:753)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1182)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1115)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:274)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:497)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:429)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1408)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1413)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

Database Locks not working

Hello!
I am having some problems with the Berkley DB XML Locking System. My database is configured as follows:
     _envConfig = new EnvironmentConfig();
     _envConfig.setRunFatalRecovery(doFatalRecovery);
     _envConfig.setRunRecovery(!doFatalRecovery);
     _envConfig.setVerboseRecovery(true);
     _envConfig.setAllowCreate(true);
     _envConfig.setCacheCount(1);
     envConfig.setCacheSize(DBCACHE_SIZE * 1024 * 1024);
     _envConfig.setInitializeCache(true);
     _envConfig.setTransactional(true);
     envConfig.setMaxLocks(MAXLOCKS);
     envConfig.setMaxLockers(MAXLOCKERS);
     envConfig.setMaxLockObjects(MAXLOCKOBJECTS);
     // enable locking
     _envConfig.setInitializeLocking(true);
     _envConfig.setLockTimeout(50000000);
     logInfo("Database locking enabled.");
     // Configure db to perform deadlock detection internally, and to
// choose the transaction that has performed the least amount
// of writing to break the deadlock in the event that one
// is detected.
_envConfig.setLockDetectMode(LockDetectMode.MINWRITE);
Then I try to modify one object in my first thread:
xmlTransaction = xmlManager.createTransaction();
               xmlContainer = xmlManager.openContainer( xmlTransaction, _collection);
               context = xmlManager.createQueryContext(XmlQueryContext.LiveValues, XmlQueryContext.Eager);
               // Declare the read/modify/write cycle
          XmlDocumentConfig docConfig = new XmlDocumentConfig();
          docConfig.setLockMode(com.sleepycat.db.LockMode.RMW);
               XmlQueryExpression xmlQueryExprDocs = _xmlManager.prepare( xmlTransaction, sQuery, xmlQueryContext);
     results = xmlQueryExprDocs.execute( xmlTransaction, _context, docConfig);
     xmlQueryExprDocs.delete();
     // document(s) found - create modify, update objects
     * Iterate over _result documents
     while (_results.hasNext()) {
                    modify = xmlManager.createModify();
                    updateContext = xmlManager.createUpdateContext();
          docValue = _results.next();
          xmlDoc = docValue.asDocument();
          numMod = modify.execute(xmlTransaction, docValue, context, updateContext);
In my second thread I try to read the same object:
xmlTransaction = _xmlManager.createTransaction(null, cfg);
XmlContainer xmlContainer = getXmlManager().openContainer(xmlTransaction, sContainer, contConfig);
context = _xmlManager.createQueryContext(XmlQueryContext.DeadValues, XmlQueryContext.Eager);
xmlQueryExpr = _xmlManager.prepare( xmlTransaction, sQuery, xmlQueryContext);
     results = xmlQueryExpr.execute( context);
And then instead of waiting on the first object to unlock the database just logs:
Transaction that opened the DB handle is still active
I just want the db to wait until the modify is ready and then do the query in the second thread.
What am I doing wrong?
Thanks for your help!
Edited by: user11285545 on 19.06.2009 04:18

Hello,
I think you want to post this to the [Db XML forum|http://forums.oracle.com/forums/forum.jspa?forumID=274] instead of the BDB JE forum.
Charles Lamb

Transactions and database locks

Similar Messages

Maybe you are looking for