Any parameter is required to set "select for Update"

Hi all,
For using "Select for Update" statement, is any parameter is required to set at the database level.
Thanks in advance,

Hi,
I did't get any problem. but before implementing that I searching for any overheads.
I had read that some transaction isolation level should be required to use "select for update".
I did't catch it clearly.
Can u explain briefly if you know/any body know.

Similar Messages

  • Select for update that doesn't return any rows

    Are there any odd side-effects that may occur if a select for update that returns no results is never committed? I wouldn't think there are, but I'm not sure if there would be some kind of overhead or unforeseen consequences. This isn't a terribly important question, but it's come up in some coding I've done and I've not been able to find any documentation addressing it.

    A select for update only locks rows that meet the predicate specified in the where clause. So, if the query returns no rows, no rows are locked.
    session1> SELECT * FROM t;
            ID DESCR
             1 Un
             5 One
             2 THIS IS WA
    session1> SELECT * FROM t
      2  WHERE id = 11 FOR UPDATE;
    no rows selectedA second session can update rows in the table
    session2> UPDATE t
      2  SET descr = 'One'
      3  WHERE id = 1;
    1 row updated.John
    Edited by: John Spencer on Jan 7, 2009 1:36 PM
    I just realized that, although you can do updates on the table after the select fo update that returns no rows, you cannot do DDL operations liike a truncate. Unless the session that does the select for update either ends the transaction (i.e. commit or rollback) or ends the session DDL operations will fail.

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

  • List current DML in DB including SELECT for Update

    In order to list all currently opened DML we can select v$open_cursor and link it to to v$SQL in order to retrieve the v$SQL.COMMAND_TYPE.
    All DML operation have the following number in v$sql.command_type :
    2 : 'INSERT'
    6 : 'UPDATE',
    7 : 'DELETE',
    189 : 'MERGE'
    But 'SELECT for update it is still 3 like any non regular SELECT.
    I did not found information in v$lock nor in v$transaction that would allow me
    to link an open cursor of type 3 (SELECT but in fact for update) to the opened transaction in v$transaction.
    Does anybody knows how to assert than a SELECT is in fact a DML short of grepping the 'FOR update' in the SQL text.
    Such an Horrible trick would force me to search all opened cursor text for each session with an entry in v$transaction.

    Thanks for replying.
    I could have had the usage of less aggressivity and more competences. You advice is simply stupid :
    -- seesion 1 :
    select * from toto where id = 20 for update ;
    select sid from v$mystat where rownum = 1 ;   -- > sid=1614
    -- session control : check v$transaction
    col version new_value version noprint
    col field new_value field noprint
    col used_urec format 999999 head 'Undo|Records'
    col undo_size head 'Undo|size (k)' justify c
    set lines 150
    select substr(version,1,instr(version,'.',1)-1) version from v$instance;
    select decode(&version,9,'','XID,') field from dual;
    Select r.segment_name,To_Char(To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS'),'MM-DD HH24:MI:SS') strt
         ,  decode(vs.status,'ACTIVE',vs.last_Call_et,0) since , vs.sid, vs.status se_status,
           &field vt.status tr_status, log_io, phy_io,cr_get,cr_change, vt.used_urec, vt.used_ublk * p.value/1024 undo_size
      From dba_rollback_segs dr,
           v$rollstat rs,
           v$transaction vt,
           v$session vs,
           v$process vp,
           dba_rollback_segs r,
           v$parameter p
      Where vs.Paddr = vp.Addr (+) AND p.name  = 'db_block_size'
       and vt.xidusn (+)  = r.segment_id
       And vs.UserName Is Not Null
       And vs.Taddr Is Not Null
       And vs.Taddr = vt.Addr
       And vt.xidusn = dr.segment_id
       And vt.xidusn = rs.usn
        Order By VS.OsUser, To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS') ;
                                   Running        Session                   Transact                                                Undo    Undo
    SEGMENT_NAME Start time       time (s)    SID Status   XID              Status       LOG_IO     PHY_IO     CR_GET  CR_CHANGE Records  size (k)
    _SYSSMU21$   04-13 11:02:24          0   1614 INACTIVE 0015002A0003A800 ACTIVE            3          0        104          0       1          8
    -- so we have a transaction in 1614. Let's retrieve its SQL :
    -- session control : what do we have in  v$session :
      1  select sql_hash_value, b.sql_text sql_text, prev_hash_value , bb.sql_text prev_sql_text
      2    from
      3       v$session  a, v$sql b, v$sql bb
      4  where sid = 1614
      5    and a.sql_hash_value = b.hash_value (+)
      6*   and a.prev_hash_value = bb.hash_value (+)
    SQL> /
    SQL_HASH_VALUE SQL_TEXT                                      PREV_HASH_VALUE PREV_SQL_TEXT
                 0                                                     897388722 select sid from v$mystat where rownum = 1
    -- gone !
    -- Conclusion : joining v$session to v$transaction is useless if you want to retrieve the SQL in system currently opened.
    -- moreover, if  start a transaction with many queries, you are still limited to 2 slot in v$session.

  • "Playlists selected for updating no longer exist"?!

    everytime i plug my ipod mini into the computer, a pop up appears saying that the playlists selected for updating no longer exist!!! it's done this before, so i completely restored the setting and made a whole new library. now it's doing it again. i have all the playlists and songs on my computer in a folder. all the songs that were on my ipod, got deleted when i plugged it into the computer. so my ipod is blank, but i have the songs in my library still. they just wont upload. any help would be greatly appreciated....

    Check this out.
    iPod cannot sync because one or more playlist....

  • 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

  • Inconsistent Locking with Select for Update

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

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

  • LOCK TABLE vs select for update

    Hello All,
    if the requirement is to lock an entire huge table to prevent any users from performing any update statement, which statement has more performance gain and why: LOCK TABLE or select fro update nowait?
    is there any overhead of using LOCK TABLE statement?
    Thanks,

    The reason I said to revoke update privilege is because I do not understand the requirement. Why do you want to prevent users from updating the table? I am assuming that users should never be allowed to update the table. In that case locking the table and select for update would be no good. If you want to stop users from updating while some one else is updating, why? All the lock table or select for update will do is cause their session to wait (hang) until the locking process commits or rolls back. This could generate a few (sic) complaints that the user application is slow/freezing.
    If you can state the business problem, perhaps we can offer a solution.

  • 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 via KODO queries

    I want to do the following in a transaction:
    1) SELECT * from Foo where type='x' FOR UPDATE
    2) UPDATE Foo set sequence='22' where type='x'
    3) commit
    The issue: is there any way to force KODO to add the 'for update' in a find query.
    Thanks

    Please try kodo.LockManager configuration property.
    -pessimistic: This is an alias for the kodo.jdbc.kernel.PessimisticLockManager , which uses SELECT FOR UPDATE statements (or the database's equivalent) to lock the database rows corresponding to locked objects. This lock manager does not distinguish between read locks and write locks; all locks are write locks.
    Also please make sure you have following setting
    kodo.jdbc.DBDictionary: SupportsSelectForUpdate=true
    Please check kodo doc section 9.4.4.
    JPA looks like
    <property name="kodo.LockManager" value="pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)"/>
    JDO looks like
    kodo.LockManager: pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)
    Thanks,
    Yun

  • Select for update gives wrong results. Is it a bug?

    Hi,
    Select for update gives wrong results. Is it a bug?
    CREATE TABLE TaxIds
    TaxId NUMBER(6) NOT NULL,
    LocationId NUMBER(3) NOT NULL,
    Status NUMBER(1)
    PARTITION BY LIST (LocationId)
    PARTITION P111 VALUES (111),
    PARTITION P222 VALUES (222),
    PARTITION P333 VALUES (333)
    ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
    CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200103, 222, NULL);
    --Session_1 return TAXID=100101
    select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_2 waits commit
    select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_1
    update TAXIDS set STATUS=1 Where TaxId=100101;
    commit;
    --Session_2 return 100101 opps!?
    --Session_1 return TAXID=100102
    select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_2 waits commit
    select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_1
    update TAXIDS set STATUS=1 Where TaxId=100102;
    commit;
    --Session_2 return 100103                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    This is a bug. Got to be a bug.
    This should be nothing to do with indeterminate results from ROWNUM, and nothing to do with read consistency at the point of statement start time in session2., surely.
    Session 2 should never return 100101 once the lock from session 1 is released.
    The SELECT FOR UPDATE should restart and 100101 should not be selected as it does not meet the criteria of the select.
    A statement restart should ensure this.
    A number of demos highlight this.
    Firstly, recall the original observation in the original test case.
    Setup
    SQL> DROP TABLE taxids;
    Table dropped.
    SQL> 
    SQL> CREATE TABLE TaxIds
      2  (TaxId NUMBER(6) NOT NULL,
      3   LocationId NUMBER(3) NOT NULL,
      4   Status NUMBER(1))
      5  PARTITION BY LIST (LocationId)
      6  (PARTITION P111 VALUES (111),
      7   PARTITION P222 VALUES (222),
      8   PARTITION P333 VALUES (333));
    Table created.
    SQL>
    SQL> ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
    Table altered.
    SQL>
    SQL> CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
    Index created.
    SQL>
    SQL>
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> Original observation:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> Session 2 with same statement hangs until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> At which point, Session 2 returns
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session2>There's no way that session 2 should have returned 100101. That is the point of FOR UPDATE. It completely reintroduces the lost UPDATE scenario.
    Secondly, what happens if we drop the index.
    Let's reset the data and drop the index:
    Session1>UPDATE taxids SET status=0 where taxid=100101;
    1 row updated.
    Session1>commit;
    Commit complete.
    Session1>drop index NI_TaxIdsStatus;
    Index dropped.
    Session1>Then try again:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> Session 2 hangs again until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> At which point in session 2:
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100102
    Session2>Proves nothing, Non-deterministic ROWNUM you say.
    Then let's reset, recreate the index and explicity ask then for row 100101.
    It should give the same result as the ROWNUM query without any doubts over the ROWNUM, etc.
    If the original behaviour was correct, session 2 should also be able to get 100101:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    taxid         = 100101
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> same statement hangs in session 2 until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> so session 2 stops being blocked and:
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    taxid         = 100101
      6  FOR UPDATE;
    no rows selected
    Session2>Of course, this is how it should happen, surely?
    Just to double check, let's reintroduce ROWNUM but force the order by to show it's not about read consistency at the start of the statement - restart should prevent it.
    (reset, then)
    Session1> select t.taxid
      2   from
      3    (select taxid, rowid rd
      4      from   taxids
      5      where  locationid = 111
      6      and    nvl(status,0) = 0
      7      order by taxid) x
      8   ,  taxids t
      9   where t.rowid = x.rd
    10   and   rownum = 1
    11   for update of t.status;
         TAXID
        100101
    Session1>
    --> Yes, session 2 hangs until...
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> and then
    Session2> select t.taxid
      2   from
      3    (select taxid, rowid rd
      4      from   taxids
      5      where  locationid = 111
      6      and    nvl(status,0) = 0
      7      order by taxid) x
      8   ,  taxids t
      9   where t.rowid = x.rd
    10   and   rownum = 1
    11   for update of t.status;
         TAXID
        100102
    Session2>Session 2 should never be allowed to get 100101 once the lock is released.
    This is a bug.
    The worrying thing is that I can reproduce in 9.2.0.8 and 11.2.0.2.

  • 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

  • OpenSQL DataSource not allowed if select-for-update is used Error?

    Hi,
    I have created an enterprise application, EJB (Session + entity) + WAR, and corresponding ear file deployes with the following warning message, I have done similar apps in the past without erros.
    Warning: DataSource TMP_EMPLOYEES_DATA is OpenSQL. It is used by an abstract schema that uses select-for-update locking. It is now allwed to use OpenSQL DataSource if select-for-updaet is used.
    Any idea?
    Thanks

    Hi Ezatullah, all,
    while I do not propose an alternative solution, I'd like to add some explanation to the error message itself: Open SQL for Java strives to provide portable semantics across the set of supported databases and does not offer features which can not be provided by all the databases.
    Now, a SELECT .. FOR UPDATE in the semantics as used here is not generally available, in particular not regarding the locking semantics.
    Thus, the feature is rejected in combination with a Open SQL/JDBC data source.
    Best Regards, Dietmar

  • Is SELECT FOR UPDATE lock ever released?

    Hi,
    Does any one know whether the lock acquired by SELECT FOR UPDATE will ever be released if user session ends without commit or rollback(e.g. crashed)? If it does, is there a default parameter to control the maximum wait time for Oracle to release the lock automatically?
    Thanks,
    JM

    Your select statement won't be committed if the db crashes. That is a DML (data manipulation language)statement. In your scenario everything is rolled back upto the last commit or savepoint. For DDL (data definition Language) for the same situation you would get an implicit commit.
    Hope this helps.

  • 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

Maybe you are looking for