Concurrent access problem with Midas

[marechal]

Hi-

We are using Borland C++Builder with Midas.
All our DOA objects are on the Midas server and we access them from the client via clientdatasets and datasetproviders.

Our datasetprovider has the ResolveToDataSet attribute set to true.
TOracleDataSets' select clauses contains the rowid reference; locking mode is set to lockImmediate.

We have a problem with the following scenario:
1) A user load the data from our application.
2) Another user modify these data and apply the updates. A commit is then automatically executed by DOA.
3) When the first user calls ApplyUpdates(0) an error message shows that another user has modified the same data and a rollback is automatically executed by DOA. (Until then everything is correct!)
4) When the first user try to post other changes to the same dataset, DOA never commit again, except when the application is leaved.

How do I have to proceed to have the commit each time an apply updates is executed from the client application?

Thanks for your help!

Alain

 

[Marco Kalter]

TClientDataSet.ApplyUpdates will always implicitly commit or rollback, unless you set the TOracleDataSet.CommitProviderTransactions property to False. Are the uncommitted changes also posted and applied through a client dataset?

------------------
Marco Kalter
Allround Automations

 

[marechal]

Hi Marco-

In the C++ TOracleDataSet, the CommitProviderTransactions attribute is not published, thus is only accessible via a programming instruction (e.g. ds->CommitProviderTransactions=true).
Anyway, we haven't modified this attribute, since it's already (and always) set to true.

All our database accesses are made through ClientDataSets, strictly following the Midas model, that is:
- On the client:
ClientDataSet
- On the Midas application server:
DataSetProvider
OracleDataSet
OracleSession

We have tried many things, and used the OracleMonitor, but the commit is always missing after a concurrent access.

The OracleMonitor log is the following:
Data are loaded; we try then to modify three records but somebody has, in the meantime, already modified one of them:
"Query.Execute (8 records processed) select UNITES.*, UNITES.rowid from UNITES where idService = :idService "
"Query.Execute (1 record processed) select * from UNITES where rowid = :doa__rowid for update nowait "
"Query.Execute (1 record processed) update UNITES set LIBELLE = :LIBELLE where rowid = :doa__rowid "
"Session.Rollback "
Data are correctly rollbacked, but we try again to apply our update:
"Query.Execute (8 records processed) select UNITES.*, UNITES.rowid from UNITES where idService = :idService "
"Query.Execute (1 record processed) select * from UNITES where rowid = :doa__rowid for update nowait "
"Query.Execute (1 record processed) update UNITES set LIBELLE = :LIBELLE where rowid = :doa__rowid "
"Query.Execute (1 record processed) select * from UNITES where rowid = :doa__rowid for update nowait "
"Query.Execute (1 record processed) update UNITES set LIBELLE = :LIBELLE where rowid = :doa__rowid "
The commit never comes !!!!!
When the program is closed modifications are correctly rollbacked (through OracleSession->RollbackOnDisconnect=true):
"01:17.547","00:00.016","Session.Rollback "
"01:17.672","00:00.001","Session.LogOff "

We badly need your help.

Thanks.

Alain

 

[Marco Kalter]

I can't reproduce this. The commit actually needs to come from the TDataSetProvider, which must call TDataSet.PSEndTransaction. This will lead to a commit or rollback. I'm not sure why this does not happen in your situation.

------------------
Marco Kalter
Allround Automations

 

[marechal]

Hi Marco,

I have sent you a zip file containing both client and midas application, at support@allroudautomations.nl.
Did you received it ? Did you reproduce the problem ?

I'm still looking for a solution...

Best regards
Alain

 

[Marco Kalter]

No, I don't think we received anything. I assume you sent it from the e-mail addres from your profile? Can you re-send it?

------------------
Marco Kalter
Allround Automations

 

[marechal]

I re-sent it just right now (and twice before...).

If you don't get it, can you please contact me by e-mail and I will try a reply.

Alain

 

[Gerhard]

I am experience exactly the same problem. The moment you disconnect the connection then only will it commit. We have a test application with 2 connection. Once the one connection have encountered a reconcile error we cancel it and just reopen( or refresh) the dataset, make a change and ApplyUpdates. But it never commits.

 

[Marco Kalter]

Yep, this is fixed in a 3.4.6 pre-release, which I sent to Marechal.

------------------
Marco Kalter
Allround Automations