| SQL.selectInto delivers same record [message #1831481] |
Thu, 20 August 2020 14:00  |
 Faruk Caglar
Messages: 33
Registered: August 2019 |
Member |
|
|
Hi,
I have a question regarding SQL.selectInto and transactions.
I have a service which does following steps:
1. read a row using SQL.selectInto into a formData
2. do some manipulations on the formData
3. store the row using SQL.update
In order to ensure that the row has not been manipulated by another process between step 1 and 3, step 3 has a logic to ensure that the update works on the row that has been read. If the row has been manipulated by another process meanwhile step 3 recognizes it and trigger the process by step 1 again. Unfortunately step 1 reads always the same record, regardless the manipulation, means the SQL.selectInto does not fetch the data from the DB.table the 2nd, 3rd, etc time - only the first time.
Interestingly the SQL.update does it because step 3 recognizes that the data has been manipulated.
This means this process is going to loop.
Interestingly it works when the step 3 does a SQL.commit before it triggers the process again. But I cannot do a commit at that time, because the above mentioned process is only a part of other operations, whioch need to work within one transaction.
I can not figure out, why step 1 uses always the same row-data. Is there a cache-mechanism? And is there a way to enforce that SQL.selectInto does read from the DB-.table?
Thanks in advance.
Best regards
Faruk
|
|
|
| Re: SQL.selectInto delivers same record [message #1831498 is a reply to message #1831481] |
Fri, 21 August 2020 04:19  |
Matthias Otterbach
Messages: 58
Registered: August 2015
Location: Munich |
Member |
|
|
Of course I do not know which database (meaning which implementation of org.eclipse.scout.rt.server.jdbc.AbstractSqlService is used), but for the default org.eclipse.scout.rt.server.jdbc.AbstractSqlService.selectInto(String, Object...) implementation (the only one I know) the method org.eclipse.scout.rt.server.jdbc.internal.exec.StatementProcessor.processSelectInto(Connection, IStatementCache, IStatementProcessorMonitor) is called which immediately runs the selection on the database. - There should be no cache mechanism.
You are saying that it works if step 3 triggers a commit; if you run the step 1 again - are you sure it is still in the same database transaction?
|
|
|
Powered by
FUDForum. Page generated in 0.03427 seconds
] 
Search
Help
Register
Login
Home
