How to SELECT FOR UPDATE with CMP (Oracle)

The most common database (Oracle) by default uses a scheme that does not fit into any of those isolation levels. A SELECT statement selects data at the start of the transactions, whereas a SELECT ... FOR UPDATE does something quite different. It is essential to do SELECT FOR UPDATEs before updating the row as SELECT does no lock. It's a hack that works well in practice.
1. Which isolation level is this?
2. More fundamentally, how an earth is it possible to use this scheme with CMP?! You would have to distinguish load() from loadForUpdate()! Is CMP inconsistent with Oracle?
This is a pretty big whole in the CMP spec!

No. thats no goes well.
Transaction serializable in Oracle uses a optimistic
concurrency system. And for update is a
pessimistic concurrency.
With optimistic: the system is faster but it can fail
With pessimistic: if doesnt fail (usually;)
You can solve the proble with many differents systems:
1. Edit the .xml descriptor files ans change the sql sentences.
And my prefer one.
2. Make a new jdbc driver that inherits from the original
oracledriver.
The new driver give u in "getConnection()" a new connection class that inherits from the original connection.
The executestatement and preparestatement adds the
string "for update" if the stattement was starting by select.
Configure your container to use the new driver.

Similar Messages

SELECT FOR UPDATE with the SKIP LOCK clause

Hi,
I have a query regarding the SELECT FOR UPDATE with the SKIP LOCK clause.
Whether this will be really good for parallel processing.
Also if we are selecting a set of records in a cursor whether the lock will be done at the records level once we fetch the records?
Also do we have any known issues with this one?
We are trying to figure out whether this will fit for business requirement, we are trying to do a implement a threading kind of thing for our stored procedure invocation in background using shell script.
Any suggestion or feedback on this will be helpful for us.
Thanks a lot for the support given....
Regards,
Basil Abraham.

http://www.oracle.com/technology/oramag/oracle/08-mar/o28plsql.html
Please read the above thread for few information...Thanks!

Difference in select for update of - in Oracle Database 10g and 11g

Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
DECLARE
  v_ename bonus.ename%TYPE;
BEGIN
  SELECT b.ename
    INTO v_ename
    FROM bonus b
    JOIN emp e ON b.ename = e.ename
    JOIN dept d ON d.deptno = e.deptno
   WHERE b.ename = 'Scott'
     FOR UPDATE OF b.ename;
END;
/While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
Edited by: Libor Nenadál on 29.4.2010 21:46
It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11g

The behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).

Deadlock detected during SELECT FOR UPDATE - an application error?

I have a general question about how Oracle prevents deadlocks from affecting
applications: do I need to build support into the application for handling
deadlocks when they occur in this particular scenario, or should Oracle handle
this for me? I'd like to know whether this is "normal" behavior for an Oracle
application, or if there is an underlying problem. Consider the following situation:
Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
records in the table using a different index. These indexes point to rows in a
different order from each other, meaning that a deadlock will occur if the two
statement execute simultaneously.
For illustrative purposes, consider these rows in a hypothetical table.
ALPHABET
alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
Index A results in traversing the table in ascending alphabetical order; index
B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
table--one with an ascending order execution path and one in descending order--
the two processes will deadlock at the point where they meet. If Session A
locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
B needs to lock delta, but one cannot continue until the other releases its
locks.
This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
-- Session A
select /*+ index_asc (customer) */
from customer
where gender = 'M'
for update;
-- Session B
select /*+ index_desc (customer) */
from customer
where gender = 'M'
for update;
Oracle will recognize that both sessions are in a stand-off, and it will roll
back the work performed by one of the two sessions to break the deadlock.
My question pivots on whether or not, in this situation, the deadlock gets
reported back to the application executing the queries as an ORA-00060. If
these are the ONLY queries executed during these sessions, I would think that
Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
statements. If I understand correctly,
(1) Oracle silently rolls back and replays work performed by UPDATE statements
when a deadlock situation occurs within the scope of the update statement,
and
(2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
is opened, to lock all rows matching the WHERE clause.
If this is the case, then should I expect Oracle to produce an ORA-00060
deadlock detection error for two SELECT FOR UPDATE statements?
I would think that, for deadlock situations completely within Oracle's control,
this should be perceived to the application invoking the SELECT FOR UPDATE
statements as regular blocking. Since the query execution plans are the sole
reason for this deadlock situation, I think that Oracle would handle the
situation gracefully (like it does for UPDATE, as referenced in (1)).
Notice, from the trace file below, that the waits appear to be from row locking,
and not from an artificial deadlock (e.g. ITL contention).
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
DEADLOCK DETECTED
Current SQL statement for this session:
SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
----- PL/SQL Call Stack -----
object line object
handle number name
58a1f8f18 4 anonymous block
58a1f8f18 11 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-002f004b-000412cf 37 26 X 26 44 X
TX-002e0044-000638b7 26 44 X 37 26 X
session 26: DID 0001-0025-00000002 session 44: DID 0001-001A-00000002
session 44: DID 0001-001A-00000002 session 26: DID 0001-0025-00000002
Rows waited on:
Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
Thanks for your insight,
- Curtis
(1) "Oracle will silently roll back your update and restart it"
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
(2) "All rows are locked when you open the cursor, not as they are fetched."
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
Message was edited by:
Curtis Light

Thanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
(1) The UPDATE statement handles this situation automatically, and
(2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction.

Inconsistent Locking with Select for Update

Hi,
I seem to be having some issues in using SELECT FOR UPDATE and was hoping to get some insight from the Oralce Guru's out there.
I have a J2EE application, running in WebLogic 8.1.4 using Oralce 9.2.0.1.0.
The application contains code that requires locking to be done on a specific table with multiple transactions (tx) requesting the same lock. Eg:
Tx 1: Select * from Zone where Zoneid = 'Zone1' for update (Obtains lock)
Tx 2: Select * from Zone where Zoneid = 'Zone1' for update (waits)
Tx 100: Select * from Zone where Zoneid = 'Zone1' for update
Tx1 commits.
It appears that the following transactions, i.e. Tx2 - Tx100 do not seem to execute in the order the lock was requested. That is Tx 100 always appears to be the second last transaction to execute, after which some arbitrary transaction between Tx2 - Tx99 will execute after Tx100 has committed.
This seems to tell me that the lock is not being handed in a FIFO manner and is causing us great pain as our data is not longer consistent.
Does anyone know how i might be able to trace which transaction is being awarded the lock? Also if anyone has any suggestion on how to troubleshoot/solve this issue, greatly appreciated.
TIA
Prem

Oracle does not have a lock queue/manager at all. The locked status of a record is essentially an attribute of the record itself. It is stored on the datablock header. When a transaction requests a lock and can't get it, and is willing to wait (SELECT FOR UPDATE without NOWAIT), it first spins while waiting for the lock (four times as I recall), then sleeps waiting for the lock. The the more times it sleeps before getting the lock, the longer it will sleep before trying again.
What is likely happening here is that transaction 100 is still spinning when transaction 1 commits, so checks back more frequently and gets the lock first. The rest get the lock whenever they wake up and noone else has taken the lock.
If you need the transaction to occur in order, then I do not think you can use Oracle's native locking mechanism. Depending on what exactly you are trying to do, you may want to look at Advanced Queueing, or possibly the built-in package DBMS_LOCK.
HTH
John

Lock Cascade With Select for UPDATE

If I had a employee table and a phone table with a parent/child relationship and a primary key constraint on the employee table-will issuing a select for update on the employee also lock the corresponding child rows on the phone table ?
If not how can I bring this about ?

You only need two sessions:
First session: Issue the 'select for update'
statements for the row(s) in both tables, don't
rollback or commit
Second session: try to update a row that you tried to
lock in the first session (with NOWAIT).
Thanks. I can try this definitely. A basic question.
You are asking me to do a join on both the tables right ?
Not two individual SQL statements ?
Updating the primary key is known as a Bad Idea (tm).
The key should never be touched because it should be
meaningless. When you have a column that holds 'real'
information it is no candidate for a primary key.
Rgds,
GuidoYes I am aware of that. I was just wondering what is the meaning behind this statement from this link ?
http://www.akadia.com/services/ora_locks_survival_guide.html
And the exact phrase from that link under the section Referential Integrity Locks (RI Locks)
"RI constraints are validated by the database via a simple SELECT from the dependent (parent) table in question-very simple, very straightforward. If a row is deleted or a primary key is modified within the parent table, all associated child tables need to be scanned to make sure no orphaned records will result. "
Thanks again.

Oracle select for update: not releasing lock

My JDBC code uses "select for update" to modify record in Oracle database. I tried to simulate network connection down situation.
After my JDBC code locked on a record using "select for update", I unplugged the network cable. I then tried to run the same code on another computer, but it could not accquire the lock, because the previous lock was not released. I tried sqlplus to lock the record, but failed also. The lock has been there for at least an hour now. I guess it may finally be released, but is there a way for oracle to release the lock as soon as the connection is down? Not know if it is a JDBC setting or oracle setting.

Dear Friend,
What you are trying to do is not correct way of checking the concurrency and transaction.
The reason is as listed below.
01.Always remember http is a stateless protocol and removing the connection or just closing the browser will never be informed to the database or to the application server thus the transaction monitor (TM)or processor will never release the lock as it will deem that the actor is manipulating the data.
02.As per locking goes every database is having a �TM� and the default isolation level setting is different like oracle uses serializable DB2udb 7.0 or db2/As400 uses repeatable read. You can change this setting by editing the default setting in the database but be very sure before touching it.
03. You can also transpose this with your Application server setting for that piece of code or Globally but again be very sure about it as it will change the entire gamete.
04. For releasing lock you have to manually do it or you can change the settings of App server or the Database to release the connection after some wait time.
Regards,
Ruchir

Trigger with SELECT-FOR-UPDATE

There is a trigger on a table, which updates a particular column with SYSDATE BEFORE an INSERT OR UPDATE in the table.
CREATE OR REPLACE TRIGGER my_schema.trg_Order
BEFORE INSERT OR UPDATE
ON my_schema.ORDER
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:NEW.LAST_UPDATE_DATE := SYSDATE;
END;
If I update the record using PL/SQL with SELECT-FOR-UPDATE & then UPDATE, the column LAST_UPDATE_DATE is not updated with the SYSDATE.
But if it is done by using the UPDATE Statement, then the column LAST_UPDATE_DATE is correctly updated with the SYSDATE.
Why? How can I ensure that for SELECT-FOR-UPDATE & then UPDATE will also update the LAST_UPDATE_DATE with SYSDATE.

The Table Order has a BLOB column.

Updatable View issues: cannot select FOR UPDATE from view with DI

Hi All,
I have a simple view XY and an instead of trigger on that to insert data into one table which is used in the my view. When I do insert statement on view XY it is working fine from sql but when i used same thing with page process of " Process Row of XY Automatic Row Processing (DML) " i am getting following error. I am using APEX 3.0 . Please help me.
ORA-20001: Error in DML: p_rowid=xxxx, p_alt_rowid=abc, p_rowid2=, p_alt_rowid2=. ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
Thanks

James,
are you already on 3.0.1.00.07 or 3.0.1.00.08? Have a look at the release notes, it says something about a bug fix for some occurrences of ORA-02014.
Also have a look at the new substitution value/item FSP_DML_LOCK_ROW which turns locking off if you set it to FALSE. See http://www.oracle.com/technology/products/database/application_express/html/3.0.1_readme.html#CHDIDIAF and also http://download-west.oracle.com/docs/cd/B32472_01/doc/appdev.300/b32471/advnc.htm#BCGFDAIJ
Patrick
My APEX Blog: http://inside-apex.blogspot.com
The ApexLib Framework: http://apexlib.sourceforge.net
The APEX Builder Plugin: http://apexplugin.sourceforge.net/ New!

How to avoid 'select for update'

Hi,
we are using the bc4j framework of jdev 3.2.3. We have a View which collects data from several tables in different database schemes, so we naturally have to use the 'union clause'. But if we try to make an update on a row (via 'setAttribute'), we got a DMLException ORA-02014 telling us that we should not use 'select for update' on views whith unions.
Since i cannot avoid using a union clause, is there a way to avoid the 'select for update' in the bc4j framework?
Please help, its urgent!
Thanx,
Dietmar

SELECT FOR UPDATE is used for our implementation or row-level locking.
If you are using pessimistic locking mode, this will occur the first time any attribute is modified.
If you are using optimistic locking mode, it will be deferred until post/commit time.
If you are using "none" locking mode, it will not happen in your application may hang indefinitely if another session has locked the row.
Are you asking how to avoid locking?
Do you mean to be updating this view with a union over multiple databases?

I hv iPhone with ios 6.0.2 My iphone could not able to check for update-it's just showing "checking for updates" with loading sign How can I upgrade to ios 7? Help pls

I hv iPhone with ios 6.0.2
My iphone could not able to check for update…it’s just showing “checking for updates” with loading sign
How can I upgrade to ios 7?
Help pls

I agree- I apologize if I sounded skeptical and attacking. In no way did I mean it to sound that way.
I completely agree on the software-hardware combo issue- this is why apple killed off 1G and 2G devices- because newer software revisions would never ever run well if at all on such ancient devices. can you imagine running iOS 6 on an iPhone/iPod touch 1G? That would be terrible. Let alone iOS 3 runs terrible on them and now are generally rendered useless due to newer App Store requirements (most require 4.3+ now to allow apple to kill off the older devices). forcing newer software on older hardware (apple, dell, HP,... Anything electronic this definitely applies to) will almost always yield less-than-par results. The other part is apple forcing you to upgrade by means of intentially making things obsolete. all companies do that.
All of this factual info aside, the issue at hand with the 5 is not a software-hardware combo problem- those are most widely seen with the major revisions. then again, this isn't the first time apple has gotten caught up in battery drain snafus (even iOS 5 was plagued with this as well- and now there are some people desperate to roll back but can't). it basically waters it down to the point where keeping the stock software will always yield the best results even though newer versions provide better features- it all depends on whether or not the person deems the added features are worth a performance hit.
PS. I'm still at 100%- and I've been using it periodically throughout the day. your combo worked for you, but didn't for me. And may or may not work for others- As the tech world would say, mileage may vary.
PSS. What model/carrier do you have? Just wondering.

Java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from

Experts,
I am getting "java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc" exception and it leads to one or more setter methods of the VO. I checked the respective attribute in the VO to see if it refers to any LOV with sql having Distinct or group by clause, but it is a normal attribute.
Any idea how do i resolve this error ?
Error Stack::
java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
     at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
     at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)
     at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:204)
     at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:540)
     at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:217)
     at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:924)
     at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1261)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1419)
     at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3752)
     at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3806)
     at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1667)
     at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:135)
     at oracle.jbo.server.OracleSQLBuilderImpl.doEntitySelectForAltKey(OracleSQLBuilderImpl.java:869)
     at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelect(BaseSQLBuilderImpl.java:553)
     at oracle.jbo.server.EntityImpl.doSelect(EntityImpl.java:8259)
     at oracle.jbo.server.EntityImpl.lock(EntityImpl.java:5964)
     at oracle.jbo.server.EntityImpl.setAttributeValueInternal(EntityImpl.java:3756)
     at oracle.jbo.server.EntityImpl.setAttributeValue(EntityImpl.java:3635)
     at oracle.jbo.server.AttributeDefImpl.set(AttributeDefImpl.java:3203)
     at oracle.jbo.server.EntityImpl.setAttributeInternal(EntityImpl.java:1971)
     at oracle.jbo.server.AttributeDefImpl.resolveSet(AttributeDefImpl.java:3412)
     at oracle.jbo.server.EntityImpl.setAttrInvokeAccessor(EntityImpl.java:1952)
     at oracle.jbo.server.EntityImpl.setAttribute(EntityImpl.java:1879)
     at oracle.jbo.server.ViewRowStorage.setAttributeValue(ViewRowStorage.java:2327)
     at oracle.jbo.server.ViewRowStorage.setAttributeInternal(ViewRowStorage.java:2131)
     at oracle.jbo.server.ViewRowImpl.setAttributeInternal(ViewRowImpl.java:1427)
     at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl.setNationality(PartyVORowImpl.java:2103)
     at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl$AttributesEnum$19.put(PartyVORowImpl.java:207)
     at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl.setAttrInvokeAccessor(PartyVORowImpl.java:4204)
     at oracle.jbo.server.ViewRowImpl.setAttribute(ViewRowImpl.java:1063)
     at oracle.jbo.server.ViewRowImpl.setAttribute(ViewRowImpl.java:1003)
     at oracle.jbo.server.ViewRowImpl.setAttributeValues(ViewRowImpl.java:1677)
     at oracle.adf.model.binding.DCDataControl.setAttributesInRow(DCDataControl.java:2427)
     at oracle.jbo.uicli.binding.JUCtrlValueBinding.setAttributeValuesInRow(JUCtrlValueBinding.java:967)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.setTargetAttrsFromLovRow(JUCtrlListBinding.java:2778)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.updateTargetFromSelectedValue(JUCtrlListBinding.java:2906)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.setAttributeFromValueList(JUCtrlListBinding.java:2851)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.setSelectedIndex(JUCtrlListBinding.java:1745)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.setInputValueInRow(JUCtrlListBinding.java:3499)
     at oracle.jbo.uicli.binding.JUCtrlValueBinding.setInputValue(JUCtrlValueBinding.java:2804)
     at oracle.jbo.uicli.binding.JUCtrlValueBinding.setInputValue(JUCtrlValueBinding.java:2767)
     at oracle.adfinternal.view.faces.model.binding.FacesCtrlListBinding.setInputValue(FacesCtrlListBinding.java:226)
     at oracle.jbo.uicli.binding.JUCtrlValueBinding.put(JUCtrlValueBinding.java:2424)
     at oracle.jbo.uicli.binding.JUCtrlListBinding.put(JUCtrlListBinding.java:3395)
     at javax.el.MapELResolver.setValue(MapELResolver.java:229)
     at com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:252)
     at com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:278)
     at com.sun.el.parser.AstValue.setValue(Unknown Source)
     at com.sun.el.ValueExpressionImpl.setValue(Unknown Source)
     at org.apache.myfaces.trinidad.component.UIXEditableValue.updateModel(UIXEditableValue.java:289)
     at org.apache.myfaces.trinidad.component.UIXEditableValue.processUpdates(UIXEditableValue.java:252)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl$UpdateModelValuesCallback.invokeContextCallback(LifecycleImpl.java:1320)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1410)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnNamingContainerComponent(UIXComponentBase.java:1380)
     at oracle.adf.view.rich.component.fragment.UIXRegion.invokeOnComponent(UIXRegion.java:555)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.invokeOnComponent(ContextSwitchingComponent.java:194)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at oracle.adf.view.rich.component.fragment.UIXInclude.invokeOnComponent(UIXInclude.java:147)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
     at oracle.adf.view.rich.component.rich.RichDocument.invokeOnComponent(RichDocument.java:168)
     at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:720)
     at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:678)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:334)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:186)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
     at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
     at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
     at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:205)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:106)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
     at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:271)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:177)
     at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at com.awRostamani.leadWeb.ui.filter.SecurityCheckFilter.doFilter(SecurityCheckFilter.java:80)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:175)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
     at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
     at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
     at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
     at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
     at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
     at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
     at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
     at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
thnks

When trying to commit from business tester, then also the following error is coming
Jdev 11.1.1.5 - locking mode is optimistic.
OracleSQLBuilderImpl.doEntitySelect failed...
java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
     at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
     at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)
     at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:204)
     at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:540)
     at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:217)
     at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:924)
     at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1261)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1419)
     at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3752)
     at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3806)
     at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1667)
     at oracle.jbo.server.OracleSQLBuilderImpl.doEntitySelectForAltKey(OracleSQLBuilderImpl.java:869)
     at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelect(BaseSQLBuilderImpl.java:553)
     at oracle.jbo.server.EntityImpl.doSelect(EntityImpl.java:8259)
     at oracle.jbo.server.EntityImpl.lock(EntityImpl.java:5964)
     at oracle.jbo.server.EntityImpl.beforePost(EntityImpl.java:6484)
     at oracle.jbo.server.EntityImpl.postChanges(EntityImpl.java:6665)
     at oracle.jbo.server.DBTransactionImpl.doPostTransactionListeners(DBTransactionImpl.java:3286)
     at oracle.jbo.server.DBTransactionImpl.postChanges(DBTransactionImpl.java:3089)
     at oracle.jbo.server.DBTransactionImpl.commitInternal(DBTransactionImpl.java:2093)
     at oracle.jbo.server.DBTransactionImpl.commit(DBTransactionImpl.java:2374)
     at oracle.adf.model.bc4j.DCJboDataControl.commitTransaction(DCJboDataControl.java:1608)
     at oracle.adf.model.binding.DCDataControl.callCommitTransaction(DCDataControl.java:1416)
     at oracle.jbo.uicli.binding.JUCtrlActionBinding.doIt(JUCtrlActionBinding.java:1437)
     at oracle.adf.model.binding.DCDataControl.invokeOperation(DCDataControl.java:2149)
     at oracle.jbo.uicli.binding.JUCtrlActionBinding.invoke(JUCtrlActionBinding.java:740)
     at oracle.jbo.uicli.jui.JUActionBinding.actionPerformed(JUActionBinding.java:193)
     at oracle.jbo.uicli.controls.JUNavigationBar.doAction(JUNavigationBar.java:412)
     at oracle.jbo.jbotester.NavigationBar.doAction(NavigationBar.java:111)
     at oracle.jbo.uicli.controls.JUNavigationBar$NavButton.actionPerformed(JUNavigationBar.java:118)
     at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
     at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
     at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
     at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
     at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
     at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
     at java.awt.Component.processMouseEvent(Component.java:6289)
     at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
     at java.awt.Component.processEvent(Component.java:6054)
     at java.awt.Container.processEvent(Container.java:2041)
     at java.awt.Component.dispatchEventImpl(Component.java:4652)
     at java.awt.Container.dispatchEventImpl(Container.java:2099)
     at java.awt.Component.dispatchEvent(Component.java:4482)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
     at java.awt.Container.dispatchEventImpl(Container.java:2085)
     at java.awt.Window.dispatchEventImpl(Window.java:2478)
     at java.awt.Component.dispatchEvent(Component.java:4482)
     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:644)
     at java.awt.EventQueue.access$000(EventQueue.java:85)
     at java.awt.EventQueue$1.run(EventQueue.java:603)
     at java.awt.EventQueue$1.run(EventQueue.java:601)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
     at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
     at java.awt.EventQueue$2.run(EventQueue.java:617)
     at java.awt.EventQueue$2.run(EventQueue.java:615)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:614)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
     at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
[348] JUErrorHandlerDlg.reportException(oracle.jbo.DMLException)
[349] DBG: afterActionPerformed :javax_swing_JToolBara1_175
Edited by: in the line of fire on Jul 12, 2011 2:54 PM

DBMS_LOCK vs Select for update locking

Hi,
In one of our database packages, we are using the dbms_lock (that package is used to generate unique numbers) instead of select for update locking.
I want to ask what is more suitable here. Our application is oracle forms and oracle db on oracle app server.
Are there any limitations to select for update locking?
What are the conditions favourable to use DBMS_LOCK?
Regards,

DBMS_LOCK is extremely efficient. Try it. Put a call to obtain/free a lock in a loop and see how long it takes to loop a few thousand times (don't SLEEP in the loop, just obtain and free the lock). If you are having performance issues with DBMS_LOCK or your select it is probably because whatever it is that gets the lock (whichever way you get it) is taking a certain amount of time to finish.
I too, am curious as to what "issues" you had. In either case, a lock for consistent read will be different than a lock for update (as it should be) in terms of how it impacts other users.

Memory Leak - select for update

Hi All.
Doing an application using OCI 8.1.7 I faced with a memory leak. (or it seems to). The leak is caused by OCIStmtExecute with SELECT FOR UPDATE statement when the iters parameter of that function is 0. In all other cases it works Ok. Below you can find a code causes a leak:
const char* sqlStatement = "select integercol from test_types for update";
OCIStmt* ociStatementHandle = 0;
OCIHandleAlloc(ociEnvHandle,(dvoid **)&ociStatementHandle,
OCI_HTYPE_STMT, (size_t) 0, (dvoid **) 0));
OCIStmtPrepare(ociStatementHandle, ociErrorHandle,
(text*)sqlStatement, strlen(sqlStatement), OCI_NTV_SYNTAX, OCI_DEFAULT));
int int_test;
OCIDefine* ociDefineHandle = 0;
OCIDefineByPos(ociStatementHandle, &ociDefineHandle, ociErrorHandle,
1, (dvoid *)&int_test, (sword) sizeof(int), SQLT_INT, (dvoid *) 0, (ub2 *)0,
(ub2 *)0, OCI_DEFAULT));
ub4 iters = 0; // (0 causes a leak)
for( int i=0; i < 100000; i++ )
OCIStmtExecute(ociServiceHandle, ociStatementHandle, ociErrorHandle, iters, (ub4) 0, (CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT));
If I change iter to 1 the leak disappears, but it is not suitable of course. Oracle documentation says following:
iters (IN)
For non-SELECT statements, the number of times this statement is executed is equal to iters - rowoff.
For SELECT statements, if iters is non-zero, then defines must have been done for the statement handle. The execution fetches iters rows into these predefined buffers and prefetches more rows depending upon the prefetch row count. If you do not know how many rows the SELECT statement will retrieve, set iters to zero.
This function returns an error if iters=0 for non-SELECT statements.
Did somebody face the problem? Do you know how to fix it?
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Bjorn Engsig ([email protected]):
Are you saying, that the memory leak disappears if you don't do 'for update' in the query?
Also, is the memory leak on the client or server side?<HR></BLOCKQUOTE>
Yes, the leak appeares ONLY for 'select ... for update' statements.
It is a client side leak, the client is Win2000.
null

Select for update returns no rows even though there is no locking thread

I'm using Ibatis library over oracle sql for my query. The select for update statement returns no rows. This happens intermittently. When this was happening last time, I executed the select statement on sqldeveloper (but without the 'for update') and got rows. This situation is not easily reproducible so I've not yet been able to ascertain whether rows are returned on sqldeveloper with the 'for update' clause. But I know for sure that there was no other thread locking the rows. How could this be happening?

The select for update statement returns no rowsWhy do you think that a select for update will always return rows?
the for update clause if there not to garantee the presence of rows but to lock the row when it is present
sql> select * from t;
         A          B C
         1          1 step1
         2          2 step2
         3          3 step3Then session 1 issues the following select
SELECT     *
      FROM t
     WHERE a = 1
FOR UPDATE NOWAIT;If session 2 issues the same select before session 1 commits or rolls back
SELECT     *
      FROM t
     WHERE a = 1
FOR UPDATE NOWAIT;It will get the following error
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specifiedBut if session 2 issue such a kind of select
sql> SELECT     *
2        FROM t
3       WHERE a = 99
4 FOR UPDATE NOWAIT;
no rows selectedYou see then that a select for update can return no rows
Best Regards
Mohamed Houri

How to SELECT FOR UPDATE with CMP (Oracle)

Similar Messages

Maybe you are looking for