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.

Similar Messages

  • 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.

  • 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

  • Disallow select for update

    Hi,
    I am making a read only user, with select rights on all of the tables in another scheme. How do I dissalow this user to lock the production table with select for update?
    Regards
    Nico

    Good idea in principle, but there may be more efficient solutions than DISTINCT. Any operation which prevents view merging appears to work (or rather not work) e.g.
    CREATE OR REPLACE VIEW view_name
    AS
       SELECT /*+ NO_MERGE */ column_name
       FROM   table_name;...is sufficient to raise ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. when attempting SELECT ... FOR UPDATE.
    It is important to note though that /*+ NO_MERGE */ could theoretically be ignored by the optimizer - another cheap alternative you might consider would be to reference ROWNUM in the view definition, e.g.
    CREATE OR REPLACE VIEW view_name
    AS
       SELECT column_name
       FROM   table_name
       WHERE  ROWNUM >= 1;

  • 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

  • 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!

  • 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!

  • VPD problem: select for update on join tables with policy on ref table

    In our application we use VPD. Now we ran into an issue. I will try to explain with EMP and DEPT table.
    EMP table has no VPD attached.
    DEPT table has VPD policy that forbids all updates, but allows select. (Policy returns '1=2' for statement type update.
    This query returns no rows:
    select * from emp join dept using (department_id) for update. This makes sense, because I'm going to update both the tables.
    However:
    select * from emp join dept using (department_id) for update of employee_id also returns no rows. THIS IS WRONG. I'm not going to update dept table.
    Any experience with this. Is this a known limitation ?

    I can see all the rows, because there is no select policy.
    However the point is, that VPD should allow me to update the emp table, because there is no update policy.
    With the 'for update of employee_id' clause, VPD should recognize that I'm not going to update the dept table, but only the emp table. But VPD does not recognize this, but applies the update policy of dept to the statement, making the statement to update no rows.
    (Reason behind my question is ADF Business Components, where you have ViewObjects with Referenced Entities. ADF BC generates this type of statement and now we run into this VDP limitation)

  • 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.

  • [Forms6]Select for update before update and commit

    Hi,
    In the KEY-COMMIT forms trigger
    My code finds the primary keys of the rows to be updated,
    then there is "select ...where "these keys".. for update nowait"
    then there is a commit
    (There also is a pragma exception init -54 "Resource Busy")
    At runtime I get an error:
    "Cannot insert rows here".
    Maybe I should lock these rows before triggering the Key-commit?
    --> message edited
    Oops, I just reproduced the code in Forms 10,
    I select for update from emp where empno=7839 then update King's sal then commit_form;
    and everything works fine.
    So I have to locate where this error message comes from.
    --< End of edit
    Many thanks for your help.
    Edited by: JeanParis on Dec 23, 2009 10:31 PM

    Hi,
    The issue is solved on my Developer 2000 10 installed on Windows XP.
    At work on Forms 6 I have hidden the warning with a :system.message_level.
    What I'm searching now is a script to check the locks in the situation where
    I don't have access to the catblock.sql script because I'm not DBA on the database. (but I can see DBA_LOCKS).
    The problem starts because on the master block there is an item that can ben changed
    from 'CREAT' to 'VALID', and in the When Validate Item trigger on that item I cannot issue a go_block( 'xxx' ).
    I have to go to the 'xxx' block in order to start a first record - next loop to gather values and update a table accordingly.
    Many thanks for your care.
    JBM.

  • Error message: "playlists selected for updating no longer exist"

    I tried to update my ipod nano and I guess I had deleted a playlist, but since then, I have not been able to update. Every time I try, I get the following message:
    "Cannot be updated because all of the playlists selected for updating no longer exist."
    I haven't been able to highlight which playlists are selected to begin with.
    I read through the manual and thought that maybe rebooting the whole system might work. So I deleted Itunes from my computer and re-installed.
    Then I tried re-setting my ipod. So now I have nothing on my ipod.
    I also deleted everything from my library, thinking it might help to start from scratch. Nothing has worked.
    How do I "select" and "unselect" playlists so I can get up and running again?

    Here you go.
    http://discussions.apple.com/thread.jspa?messageID=607312&#607312

  • "All of the Playlists Selected for Updating No Longer Exist"

    My family has 2 ipod shuffles. After purchasing a Nano recently, I inserted the cd that came with it. Apparently the existing iTunes software was removed and reinstalled. At any rate, the library still shows all the original songs, but when the Nano is plugged in, iTunes immediately gives a prompt stating "Songs on the iPod *** cannot be updated because all of the playlists selected for updating no longer exist." The library is there, the playlists that were there are there, and I can play the songs on my cpu. Is there anything I can do besides completely uninstalling everything and starting over?
    iPod Nano   Windows XP Pro  

    This user tip should help you sort out your missing playlist problem: Hudgie - iPod cannot sync because one or more playlists are missing

  • LOB: Select for update

    I keep getting this error with some pretty standard CLOB code to update data:
    HELLLP!!!
    SQLException: ORA-01002: fetch out of sequence
    java.sql.SQLException: ORA-01002: fetch out of sequence
    Here's the code:
    CLOB lob_loc = null;
    String buf = new String ("CLOB text buffer test");
    Connection myConn=
    DriverManager.getConnection("jdbc:oracle:thin:@172.16.11.32:1521:ORCL","outerforce","outerforce");
    Statement stmt = myConn.createStatement();
    System.out.println("BEFORE SELECT FOR UPDATE........");
    ResultSet myResultSet = stmt.executeQuery("SELECT data FROM clobtest WHERE assign_no=7 FOR UPDATE");
    System.out.println("SELECT DONE FOR UPDATE........");
    if (myResultSet.next())
    lob_loc = ((OracleResultSet)myResultSet).getCLOB (1);
    OracleCallableStatement cstmt = (OracleCallableStatement)
    myConn.prepareCall ("BEGIN DBMS_LOB.OPEN(?, DBMS_LOB.LOB_READWRITE); END;");
    cstmt.setCLOB(1, lob_loc);
    cstmt.execute();
    /* if (myResultSet != null){
    while (myResultSet.next()) {
    System.out.println(myResultSet.getString("assign_no"));
    long pos = 0; // This is the offset within the CLOB where the data is to be written
    long length = 0; // This is the size of the buffer to be written.
    // This loop writes the buffer three times consecutively:
    //for (int i = 0; i < 3; i++)
    // Fill the buffer with some data to be written:
    length = buf.length();
    //pos += length;
    // This is an Oracle-specific method:
    //lob_loc.plsql_write(pos, buf.toCharArray());
    lob_loc.putString(pos, buf);
    //}

    Sorry Email reply was incorrect
    send to:
    [email protected]
    null

  • 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

  • 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.

Maybe you are looking for