× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




This is to mtodd:

If you're stuck/forced to use the legacy numbers, Dan's solution below makes sense. That is, attempt to delete the row. If nothing is deleted, presumably another user has that number, so get the next number and retry.

You can do this in a simplified way without transactions or commitment control, by using a delete statement and executeUpdate():

iCount = ps.executeUpdate();

If the count is zero, the operation affected no rows. Notice that you don't get an exception in this case.


Joe Sam

Joe Sam Shirah - www.conceptgo.com (904) 302-6870
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: www.ibm.com/developerworks/java
Just the JDBC FAQs: www.jguru.com/faq/JDBC
Going International? www.jguru.com/faq/I18N
Que Java400? www.jguru.com/faq/Java400




-----Original Message----- From: Dan Kimmel
Sent: Wednesday, October 10, 2012 11:11 AM
To: Java Programming on and around the IBM i
Subject: RE: Locking of record using SQL in JAVA Websphere application.

What goes on in your deleteMemberNumber() method?

If it was me, I'd just use rs.deleteRow() in its place.

I also think you need a rollback() in your exception handlers, though closing the connection without a commit will force a rollback.

Under commitment control, I don't think "FOR UPDATE" is going to preclude another thread from reading the same record. You have to rely on deleteRow() to throw an exception in the thread that loses the race.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of mtodd@xxxxxxxxxxxx
Sent: Tuesday, October 09, 2012 7:44 AM
To: java400-l@xxxxxxxxxxxx
Subject: Locking of record using SQL in JAVA Websphere application.


Have Web app that reads record from iSeries to get a unique number, then deletes that record.

Need to make sure that only one web user gets that unique number.

Application seems to work 99% of the time but sometimes log reports duplicate key error message when using unique number to write to transaction file. This seems to suggest that more than one user retrieved the unique number.

I use SQL to access the iSeries, setting the connection to TRANSACTION_SERIALIZABLE to lock the record.

Appreciate any help on this issue.

Many thanks.

Below is the code :

sqlSelect="SELECT AMMBR# FROM MBPRDDTA.MBAMBRP WHERE AMGRWS= ? FOR UPDATE";
try{
con=AS400ConnectionManager.getInstance().getConnection();
con.setTransactionIsolation
(Connection.TRANSACTION_SERIALIZABLE);
psmt=con.prepareStatement(sqlSelect);
psmt.setString(1,memberData.getTradeIndividual());
ResultSet rs=psmt.executeQuery();
rs=psmt.executeQuery();

if(rs.next()){
response.setMemberNumber(rs.getLong("AMMBR#"));
if (deleteMemberNumber(response.getMemberNumber
(),con)){
response.setStatus
(ApplicationStatus.SUCCESS);
response.setMessage("Successfully retrieved & deleted member number from MBAMBRP");
}
}
con.commit();


}catch (SQLException e){
response.setMessage("SQL exception : Error retrieving & deleting member number from MBAMBRP");
e.printStackTrace();
} catch (PersistenceException e) {
response.setMessage("Persistence exception : Error retrieving & deleting member number from MBAMBRP");
e.printStackTrace();
}
finally{
try {
psmt.close();
con.close();
} catch (SQLException e) {
response.setMessage("SQL final exception : Error retrieving & deleting member number from MBAMBRP");
e.printStackTrace();
}
}


***********************************************************************************

CONFIDENTIALITY / DISCLAIMER NOTICE

This communication contains information which is confidential and may also be privileged.
It is for the exclusive use of the recipient(s). If you are not the intended recipient(s) please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Costco Wholesale UK Ltd. If you have received this communication in error please notify us by e-mailing the author or by telephoning (01923 213113) and then delete the communication and any copies of it.
This communication is from Costco Wholesale UK Ltd whose registered office is at UK Home Office, Hartspring Lane, Watford WD25 8JS, England.

***********************************************************************************
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.