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.

Similar Messages

Oracle select for update: not releasing lock

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

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

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

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

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.

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

"SELECT FOR UPDATE" genrating large redo

Hi,
Is there any obvious reason why a "SELECT FOR UPDATE" would cause massive amount of redo to be generated?
Derek

1. "SELECT FOR UPDATE" itself should modify block to record row level lock information. This can cause redo data. See following:
-- Create test table
SQL> create table for_update_test(id int);
Table created.
SQL> insert into for_update_test values(1);
1 row created.
SQL> commit;
Commit complete.
-- Get DBA
SQL> select dbms_rowid.rowid_relative_fno(rowid) as fno,
2 dbms_rowid.rowid_block_number(rowid) as blk_no
3 from for_update_test;
FNO BLK_NO
4 41980
-- Execute "Select for Update..."
SQL> connect user/password;
SQL> select * from for_update_test for update;
ID
1
-- Get Transaction ID
SQL> select xidusn, xidslot, xidsqn from v$transaction
where ses_addr = (select saddr from v$session where sid =
(select sid from v$mystat where rownum = 1));
SQL> /
XIDUSN XIDSLOT XIDSQN
2 24 24009
-- Dump corresponding block to identify which has been changed
SQL> alter system dump datafile 4 block 41980;
Block header dump: 0x0100a3fc
Object id on Block? Y
seg/obj: 0x1013b csc: 0x7df.1847891a itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x100a3f9 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0004.023.00004719 0x00800b41.1359.02 C--- 0 scn 0x07df.184788fe
0x02 0x0002.018.00005dc9 0x00800c54.0eef.33 ---- 1 fsc 0x0000.00000000
data_block_dump,data header at 0x6682464
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x06682464
bdba: 0x0100a3fc
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f92
avsp=0x1f7b
tosp=0x1f7b
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x1f92
block_row_dump:
tab 0, row 0, @0x1f92
tl: 6 fb: H-FL lb: 0x2 cc: 1
col 0: [ 2] c1 02
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 41980 maxblk 41980
Here you can see that the row's lock byte is "2" and the corresponding ITL entry shows that the lock owner is the session that executed "Select for update...".
So, "Select for update" does really update block and generate redo for that change.
2. Note that even "Select " statement can generate redo data. This is caused by "delayed block cleanout". Google it for more information.

Database select for update locks ADF

Hi,
When a user has initiated an update session in an adf application and locking is optimistic it will acquire a lock on table row using select for update no wait; . But when the user closes a tab the session would not be terminated. Now i know as HTTP is a stateless protocol, we can wait for the timeout and then the lock will be released using a session listener implementation. But if the user instead tries to log in again in a new tab and tries to edit the same record he will receive a message stating that another user already holds a lock on the record which is correct, but is misleading.
So can we rely on javascript for these scenarios that as soon as the user closes the tab the session should be terminated.
Here's a snippet
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.4/dojo/dojo.xd.js" ></script>
<script type="text/javascript">
var unLoad = function() {
    dojo.io.script.get({
    url:'http://127.0.0.1:7101/myapp/adfAuthentication?logout=true',
    timeout:15000,
dojo.addOnWindowUnload(unLoad);
</script>I know this might not work always as it depends on the fact that request might / might not be processed by the server.
Are there any alternate solutions and also reducing the session timeout is ruled out in my scenario.

Ramandeep,
So are there other alternatives or solutionsAlternatives or solutions to what, exactly? As Jobinesh has told you, as long as you use optimistic locking, ADF doesn't acquire database locks except in the context of a transaction that is going to be completed in the current HTTP request. You could obviously force ADF to deviate from this if you called "postChanges" during an HTTP request and leave the transaction hanging, but that would just be wrong in an optimistic locking scenario - the solution would be "don't do that."
John

SELECT FOR UPDATE - does it write to REDO?

Greetings folks,
we have some strange performance issues with a recent application update. This is custom in-house application. Every morning since the deploy we get a spike in load, especially to log sync / redo archive. We capture activity surrounding the load, and found many "select for update" statements.
Im digging through metalink and docs looking to confirm "write or no write" to the redo log files. comments appreciated.

sb92075 wrote:
SELECT does not generate REDO
DML generates REDO.It is possible for a SELECT to generate redo due to the effects of delayed block cleanout. A small test case:
Session 1:
CREATE TABLE T10 AS
SELECT
ROWNUM RN
FROM
DUAL
CONNECT BY
LEVEL<=1000;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
Session 2:
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
Session 1:
COMMIT;
Session 2:
SET AUTOTRACE ON STATISTICS
SELECT
FROM
T10;
1000 rows selected.
Statistics
          0 recursive calls
          0 db block gets
         73 consistent gets
          3 physical reads
        188 redo size
      11104 bytes sent via SQL*Net to client
       1060 bytes received via SQL*Net from client
         68 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
       1000 rows processedNote that the above may be performed in a single session rather than using two sessions. Essentially, the flush of the buffer cache causes the dirty blocks (containing uncommitted changes) to be written to disk, and the blocks are "cleaned up" during the next SELECT which accesses the blocks.
A much better explanation:
http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

How to SELECT FOR UPDATE with CMP (Oracle)

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

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

ODBC 10.2 client makes SELECT FOR UPDATE run slower

Hi all,
I'm facing a strange problem with Oracle OBDC: I got an application which needs to connect to an Oracle DB via odbc.
Server is a 10.2.0.1; if I connect using ODBC driver installed by Oracle 8 client everything is ok but if I use ODBC driver installed by Oracle 10 client or Oracle XE client SELECT FOR UPDATE statements become really slower.
My application always does the same statement:
SELECT list_of_fields
FROM table
WHERE primary_key =
AND ...
FOR UPDATE;
If I use the Oracle 8 ODBC, this select is almost immediate; but if I use Oracle 10 ODBC it tooks ~4 seconds.
The statement is identical, so the access plan must be the same.
The ODBC configuration is identical too; tnsnames.ora entries are the same.
So, why the 10x clients are slower?
thanks for every answer
andrea
Message was edited by:
user585511
Message was edited by:
user585511

Which cursor library are you using? The ODBC Driver Manager's cursor library strips off the FOR UPDATE silently (see Appendix F of the ODBC Programmer's Reference). Depending on what version of the "Oracle 8 client" you were using, there may not have been an ODBC driver cursor library, so you may have been forced to use the driver manager's. Potentially, the slowdown is that you're now actually locking the rows now and may be running some contention issues.
It would be worthwhile to trace the sessions and see what the difference in waits is.
Justin

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

Lost music on ipod because "playlists selected for updating no longer exist

Not sure what I've done. I recently downloaded newer version of itunes. Then when synching, I had too much music in my library for the ipod to handle so it told me about doing the smart playlist. I erased a couple of playlists on the itunes menu I no longer wanted and then when I went to synch, this error came up "songs on the ipod cannot be updated because all of the playlists selected for updating no longer exist."
Please help.....

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

"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

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

Select for update on stateless connections

Similar Messages

Maybe you are looking for