AM.method() issues select for update (immediately) ??

We have a thin client with BC4J optimistic locking and our own change indication logic
we're happy with.
We now need to implement a safe-region through a use case to lock a row immediately on
voOverAnEntity.executeQuerry() so that the values can be changed and then new values
set. Then the commit() flushes the changes back the DB and the lock is released.
We could write a custom SQLView and in expert mode do the select values,, from abc for update
that would dispatch the DML in real time.
What I'd like though, is for the ViewObjectImpl to support a lock feature?
myEntityVo.setWhereParam();
myEntityVo.lockTheseRows();
myEntityVo.executeQuerry();
Take the values selected, modify and row.setAttribute() ...
with safety since the rows are locked.
... Now I can modify the Rows and let the normal am.comit(); logic go on it's merry way which
is decoupled from my AMmethods.
Thanks, curt

Curt:
Please see my comments on the code snippet (marked with "From Sung:"):
myVo.setWhereClauseParam(0,theWhereValue);
myvo.executeQuerry();
Row myRow = myVo.first();
boolean haveRowLocked = false;
int     maxLoops = 0
while(!haveRowLocked && (maxLoops++ < 3))
  // This is a high concurrency row in this use case
  try {
    myRow.lock()
    haveRowLocked = true;
  } catch (JboException jex)
    // I'll figure out which specific exception is thrown later
    Thread.sleep(10 + (maxLoops * 50));   // sleep a progressively longer time
    continue;
if (!haveRowLocked)
   throw someException;
// Since we just got the lock, I need the latest values in this Row
// Is there any smarter way to do this??
// From Sung: You don't need to refresh the row after lock.
// In the process of lock(), we (BC4J) get the latest values
// for all attributes from the database and push them into
// the row.  Thus, if lock() succeeded, that means you have
// the latest values.
// From Sung: You can the calls to executeQuery() and first()
// myvo.executeQuerry();
// Row myRow = myVo.first();
// Now update the values in this row based on current state
BigDecimal balance = (BigDecimal)myRow.getAttribute ("accountBalance");
balance.add(new BigDecimal("123.45"));
myRow.setAttribute ("accountBalance", newAmt);
transaction.commit();  // update the new Amount and release the lockThanks.
Sung

Similar Messages

  • Pros and  cons  of  select  for  update  clause

    hi,
    Can anybody explain what are the
    pros and cons of select for update clause
    11.2.0.1

    As commented, there are no pros versus cons in this case.
    What is important is to understand conceptually what this do and why it would be use.
    Conceptually, a select for update reads and locks row(s). It is known as pessimistic locking.
    Why would you want to do that? Well, you have a fat client (Delphi for example) and multiple users. When userA updates an invoice, you want that invoice row(s) locked and prevent others from making updates at the same time. Without locking, multiple users updating the same invoice will result in existing updated data being overwritten by old data that also has been updated. A situation called lost updates.
    For web based clients that are stateless, pessimistic locking does not work - as the clients do not have state and pessimistic locking requires state. Which means an alternative method to select for update needs to be used to prevent lost updates. This method is called optimistic locking.
    So it is not about pros versus cons. It is about understanding how the feature/technique/approach works and when to use it.. and when it is not suited to use it. All problems are not nails. All solutions are not the large hammer for driving in nails.

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

  • Should i use SELECT for update NOWAIT ?

    Hi:
    Do I need to use, in my pl/sql triggers and procedures, the SELECT FOR UPDATE NOWAIT sentence, to avoid locks before using update table sentences ? Is it common to use it on stored procedures and triggers?
    Thanks
    Joao Oliveira

    First, what, exactly do you mean by "avoid locks"? I was interpreting that to mean "I want to avoid creating locks in my session that might block someone else", not "I want to avoid having my SELECT wait for locks to be released-- I want it to fail immediately". If you meant the latter, then SELECT ... FOR UPDATE NOWAIT would be what you want. If you meant the former, then pessimistic locking is not what you want.
    Second, what sort of Oracle Forms architecture do you have? Are you still using old-school client-server applications? Or are you using a three-tiered approach? As Tom discusses in that thread, pessimistic locking is only an option when your client application is able to maintain database state across calls (i.e. client/server systems) not when you have stateless connections (which is the norm in the three-tier model). The old client-server versions of Forms would automatically and transparently do pessimistic locking. Since you didn't mention anything about your architecture, most of us probably assumed the more common stateless client architecture (note how Tom's answers progress over the 5 years in that thread as client/server architecture became less and less common).
    Third, while your question is appropriate for either the Database - General forum or the SQL and PL/SQL forum, that generally means that you are free to post it either forum, not that it should be posted in both. The vast majority of the folks that hang out in one forum hang out in the other. It's also rather frustrating to answer a post in one forum only to discover that there is another post in a different forum where someone else had already covered the same points half an hour earlier or to discover that there was additional information in another thread that might have changed your answer.
    Fourth, if you are going to do pessimistic locking, that requires that you are able to maintain state across various database calls, that you are locking on the lowest possible level of granularity, and that you are able to time out sessions relatively aggressively to ensure that someone doesn't open a record, thereby locking it, go to lunch (or have their system die) and then block everyone else from working. Assuming that is the case, and that you have some reasonable way to handle the error that gets generated other than simply retrying the operation, adding NOWAIT is certainly an option. Most applications, particularly those getting written today, cannot guarantee all these things, so pessimistic locking is generally not appropriate there.
    Looking at your other thread (where there is new information that would be useful in this discussion, one of the reasons that multiple threads are generally a bad idea), it seems that you have an ERP application and you are concerned about the performance of entering orders. Obviously, there shouldn't be any locking issues on the ORDER or ORDER_DETAILS tables, assuming that multiple users aren't going to be inserting the same order at the same time. The contention would almost certainly come when multiple orders are trying to update the STOCK and INVENTORY tables, since multiple orders presumably rely on the same rows in those tables. In that case, I'm not sure what adding a NOWAIT would buy you-- unless you were going to roll back the entire order because someone is updating the STOCK row for #2 pencils and your order has an item of #2 pencils, you'd have to keep retrying the operation until you were able to modify the STOCK row, which would be less efficient than just letting that update block until the row was free.
    Now, you could certainly redesign the application to minimize that contention by not trying to update what I assume are aggregate tables like STOCK and INVENTORY directly as part of your OLTP processing or, at least, by minimizing the time that you're locking a row. You could, for example, make STOCK and INVENTORY materialized views rather than tables that refresh ON COMMIT, which should decrease the time that your locks are held. You could also have those tables refreshed asynchronously, which would be even more efficient but may require that you reasses your holdback requirements.
    Justin

  • Select for update on stateless connections

    i have read that using select for update for a web application will not work specially if the stateless connection are used , and the best way to make sure that the column you are reading was not changed is to use the time stamp approach and not select for update?? i am right

    Not entirely correct.
    A connection/session to Oracle has state. There is no such thing as a stateless Oracle connection.
    The stateless connection is from the web browser to the web server. It makes a connection. Asks for a page (GET, PUT or POST typically). It gets a response from the web server. It closes that connection.
    When the web server response, it opens a (stateful) connection to Oracle. Or it re-uses an existing (stateful) Oracle connection (now idle after having serviced another web browser/web server request).
    The problem with pessimistic locking (e.g. SELECT FOR UPDATE) is that the very same (stateful) Oracle session will either
    a) be closed when a response is send to the web browser
    b) be used for another totally different web browser
    Thus any locks made will either be lost (option a) or will get used by the wrong web browser (option b).
    A method is therefore needed to make the lock spans different Oracle (stateful) sessions. Web browser selects rows to update using Oracle session 101 at Time 1. Web browser submits updated rows and a commit using Oracle session 142 at Time 2.
    The "best way" to handle optimistic locking is likely using the Oracle System Change Number (SCN). This represents the "current version" of the rows.
    So at Time 1, via Session 101, you give the web browser a 100 rows to update - together with the SCN that says the current version of the rows are v1.2.0.1.
    At Time 2, using Session 142, the web browser submits its changes for those 100 rows. Together with the SCN v1.2.0.1.
    The SQL UPDATE issues the update statement - but adds the SCN version criteria. If the UPDATE fails to update all 100 rows, it means that some of the rows no longer exist, or that some rows have a new version number (was changed in the meantime).
    In this case, the UPDATE is rolled back and an exception raised to tell the web browser that some (or all) of those 100 rows have been changed in the meantime.
    Refer to the [url http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/pseudocolumns007.htm#BABFAFIC]Oracle® Database SQL Reference for details.

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

  • Rogue implicit SELECT FOR UPDATE statement in forms 9i  9.0.4.0.19

    all,
    out of 200 production forms, one form occasionally and incorrectly "selects for update" an entire 3 million row table, during an update transaction. this creates 100+ archive logs.
    we cannot repeat the event via testing. but the rogue select statement has been captured from SGA and is listed below. its plain to see that somehow the where clause is truncated to a W, and is then used as a table alias, resulting in the entire table being locked.
    has anyone seen anything like this?
    SELECT ROWID,DISTRIBUTION_PARTY,DISTRIBUTION_PARTY_NAME,CORRESPOND_SEQ_NUM,DISTRIBUTION_SEQ_NUM,VENDOR_NUM,DEPENDENT_SEQ_NUM,INTERNAL_ATTORNEY_USER_NAME,MAIL_LOC,ORIGINAL_FLAG
    FROM CLAIM_DISTRIBUTION_DATA W
    FOR UPDATE OF DISTRIBUTION_PARTY NOWAIT

    Find out where this select statement is issued from first of all. Is it in your code or is it issued implicitely by Forms? Since it has rowid I assume it is an implicit Forms call.
    Do you use on-update triggers any where in this form? on-lock?

  • 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

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

  • 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

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

  • 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

  • JDBC SELECT FOR UPDATE

    I'm trying to issue a SELECT ... FROM ... FOR UPDATE, and under specific verified conditions runs an UPDATE (where the current is positioned!).
    The error code I get is:
    ORA-01002: Fetch out of sequence.
    Here you are my code:
    /////////////////////START
    import java.sql.*;
    import oracle.jdbc.*;
    import oracle.sql.*;
    public class SelForUpdDin{
    static{
         try{
              Class.forName("oracle.jdbc.driver.OracleDriver");
         catch(Exception e){e.printStackTrace();}
    // Queries and cursor name
    public static void main (java.lang.String[] args){
    String cursorName = null;
    int codice = 0;
    String cognome = null;
    String job = null;
    int manager = 0;
    java.sql.Date dataAss = null;
    int salario = 0;
    int commissioni = 0;
    int reparto = 0;
    String rowid = null;
    String sqlSelect = "SELECT empno, ename, "+
    "job, mgr, hiredate, sal, comm, deptno, ROWID "+
    "FROM scott.emp FOR UPDATE";
    String sqlUpdate = "UPDATE scott.emp SET comm = ? WHERE ROWID = ? ";
    try {
    Connection con = DriverManager.getConnection("jdbc:Oracle:oci8:@","system","manager");
    // Esecuzione della SELECT e produzione del RESULT SET
    Statement stmt = con.createStatement();
    ResultSet rs = stmt.executeQuery(sqlSelect);
    PreparedStatement ps = con.prepareStatement(sqlUpdate);
    while (rs.next()) {
    codice = rs.getInt(1);
    cognome = rs.getString(2);
    job = rs.getString(3);
    manager = rs.getInt(4);
    dataAss = rs.getDate(5);
    salario = rs.getInt(6);
    commissioni = rs.getInt(7);
    reparto = rs.getInt(8);
    rowid = rs.getString(9);
    // Applicazione della business logic
    if (reparto == 30)
    { System.out.println (cognome + " in dept= "+ reparto +
    " with salary=" + salario + " has a commission= " +
    commissioni);
    int newcomm = 5555;
    ps.setInt(1,newcomm);
    ps.setString(2,rowid);
    ps.executeUpdate();
    else
    { System.out.println (cognome + " in dept= "+ reparto +
    " with salary=" + salario + " has a commission= " + commissioni);
    } // if - else
    } // end while
    rs.close();
    ps.close();
    stmt.close();
    catch(Exception e)
    e.printStackTrace();
    } // end main()
    } // end class
    //PS.
    //Many thanks to Bachar and Elangovan that ansewerd me to my previous posting and addressed me towards the right solution

    Hi
    The documentation gives following explanation for the error :
    ORA-01002 fetch out of sequence
    Cause: In a host language program, a FETCH call was issued out of sequence. A successful parse-and-execute call must be issued before a fetch. This can occur if an attempt was made to FETCH from an active set after all records have been fetched. This may be caused by fetching from a SELECT FOR UPDATE cursor after a commit. A PL/SQL cursor loop implicitly does fetches and may also cause this error.
    Action: Parse and execute a SQL statement before attempting to fetch the data.
    In your program you should set auto commit to false as follows :
    con.setAutoCommit(false);
    Do this before executing the SELECT FOR UPDATE sql query.
    At the end of program you can commit to save the updations as follows:
    con.commit();
    This should solve the problem.
    Chandar

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

Maybe you are looking for

  • Sharepoint Foundation 2010 calendars not linking to Outlook 2013

    We have been using linked calendars between SharePoint Foundation 2010 and Outlook 2010 for some time. I have upgraded a few users to Outlook 2013 and now cannot link the SharePoint calendars. are there any known compatibility issues?

  • Error While Running JasperReport in JSP Page

    Dear All i am running Report JasperReport using JSP and i am sure that i attached jasperreports-3.0.0.jar and i am getting this error net.sf.jasperreports.engine.JRException: Errors were encountered when compiling report expressions class file: C:\Us

  • Nokia 6280 display issue!!! Pls help!!

    Hi there everyone! I live in United States and i use nokia 6280 for almost 1 year, but recently my phone display turn black whenever I slide it up/down. and i can't make a call with black screen as my display, and i also think that this is a strange

  • ID Cache notificaions

    Hi, The Changes in ID are not updated..when i see the cache notifications it is showing that Cache instance is Integation server (ABAP Cache),Cache updated is not yet started and Perform notification failed. on the problems tab it is shown that, Unab

  • New computer won't launch iPhoto

    Good day all. I just upgraded from an iBook G4 with 10.4.5 to a shiny new iMac with 10.6.6. The Migration Assistant did a nice job of moving all my files over, but there's an issue with iPhoto. When I launch it (or attempt to), it throws an error tha