JDBC Thin: Can use "select for update"?

Hello,
Can anyone tell me if/how can I solve the concurrency
upon a result set?
JDK 1.2 documentation contains the following Connection's
method:
"public Statement createStatement(int resultSetType,
int resultSetConcurrency)
throws SQLException
JDBC 2.0 Creates ..."
Thanks,
Alexandra
null

We don't have support for JDBC 2.0 yet.
You can use SQL with 'for update' clause in the present
8i drivers. However, make sure that autoCommit
is OFF
Alexandra (guest) wrote:
: Hello,
: Can anyone tell me if/how can I solve the concurrency
: upon a result set?
: JDK 1.2 documentation contains the following Connection's
: method:
: "public Statement createStatement(int resultSetType,
: int resultSetConcurrency)
: throws SQLException
: JDBC 2.0 Creates ..."
: Thanks,
: Alexandra
Oracle Technology Network
http://technet.oracle.com
null

Similar Messages

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

Which IP addresses can use firefox for updates?

Hello
Firefox sending requests to a lot of third party IP addresses. How to know which of these addresses need to update?
Is it possible to disable requests to the Akamai servers?
P.S. I want to restrict network activity by firewall to small count trusted networks.

I am not 100% sure what you are asking.<br>
Is Firefox causing update popups to appear on the browser?<br>
If so, these are fake and you should run a full scan for malware or other infections.

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

Performance of using a Select For Update vs a correlated subquery

I was wondering wether or not it is more effecient to use the
Select ... For Update (with a cursor etc.) versus a correlated
subquery.
I can accomplish the same thing with either however performance
at our site is an issue.

Use select for update cursor as that is faster as it updates
based on the rowid. One thing to keep in mind is that rowid is
session specific and the rows to be updated get locked so that
nobody else can update them till the lock is released. I have
had very good performance results with these cursors.
Good luck !
Sudha

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

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

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

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.

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.

How to avoid 'select for update'

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

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

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

When is SELECT FOR UPDATE used

DB version:10gR2
Since another thread of mine on this subject didn't go well, i am starting another thread.
When exactly is SELECT..FOR UPDATE statement used? With the exception of using SELECT...FOR UPDATE in CURSOR declaration, I've rarely seen SELECT ...FOR UPDATE being used explicitlyby PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE(i mean a stand alone SELECT FOR UPDATE, <em>not as a part of Cursor</em>) to lock rows before UPDATE/DELETE/INSERT in their codes?
Edited by: M.Everett on Oct 20, 2008 12:00 PM
edited the initial post to let the users know that I am refering to a stand alone SELECT FOR UPDATE statement, not the part of a cursor

M.Everett wrote:
What i gather from various sources in the Internet:
1. SELECT FOR UPDATE is used mainly on CURSORs and very rarely used as a stand alone statement (if this is not the case you would have seen SELECT FOR UPDATE statements before every UPDATEs and DELETEs in PL/SQL codes)
2. Stand alone SELECT FOR UPDATEs are used mainly when dealing with CLOB, BLOB
Am i right in making these conclusions?1. This is probably a fair assumption.
2. Not really. SELECT FOR UPDATE is not a requirement when dealign with (C|B)LOBs.
SELECT FOR UPDATE allows an easy form of reference when you come to update rows in a cursor loop (although cursor loops should be rarely used), because rather than having to include a where condition on key columns you can just refer to the CURRENT ROW. Obviously, the main reason for using SFUs is the locking and this can become a requirement in some business environments where a user "picks up" a record to deal with and other users will then not see that record in their list or be able to select it for themselves.
;)

Is jdbc thin driver not designed for internet use?

Is jdbc thin driver not designed for internet use?
The size of the thin-driver file is about 1MB of size and is
too large if were to ask clients to download it from the
internet.
Can anyone advise on this issue?
null

You need to remote onto the server and go into start->control panel-Administration-> ODBC (or sometimes start->administration->ODBC) and set up ODBC connections . Make sure you set them up on the system tab, then you should see them in EAS. I don't remember, b ut don't think you need to restart the Essbase servise for them to take effect

JDBC Thin: Can use "select for update"?

Similar Messages

Maybe you are looking for