Devart Forums

Hello,
I'm connecting to Oracle 11g using EntityFramework. After envolving TransactionScope usage upon existing functional code, I frequently obtain folowing exception:

Message:
"Network error:: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"
ErrorCode:-2147467259
StackTrace:
at Devart.Data.Oracle.i.a(Byte[] A_0, Int32 A_1, Int32 A_2)
at Devart.Data.Oracle.i.a(Byte& A_0)
at xc.l.b(Byte[] A_0, Int32 A_1, Int32 A_2)
at xc.l.b()
at Devart.Data.Oracle.bj.c()
at Devart.Data.Oracle.t.a(Int32 A_0, a5 A_1)
at Devart.Data.Oracle.OracleCommand.InternalExecute(CommandBehavior behavior, IDisposable disposable, Int32 startRecord, Int32 maxRecords)
at Devart.Common.DbCommandBase.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader()
at Devart.Data.Oracle.OracleCommand.ExecuteNonQuery()
at Devart.Data.Oracle.Entity.h.a.m()
at System.Data.Mapping.Update.Internal.DynamicUpdateCommand.Execute(UpdateTranslator translator, EntityConnection connection, Dictionary`2 identifierValues, List`1 generatedValues)
at System.Data.Mapping.Update.Internal.UpdateTranslator.Update(IEntityStateManager stateManager, IEntityAdapter adapter)

The error occurres after several ObjectContext.SaveChanges() calls, all inside the same ObjectContext and TransactionScope.

Any ideas?
Thanks for advance.
Pavel

Our implementation of the TransactionScope support has the following limitation (applied to the Direct mode only): we don't support two-phase commit mechanism, only simultaneous commit in several connections is implemented. So a particular table in your database was locked after the first SaveChanges(). And if the consequent SaveChanges() in the boundaries of your TransactionScope will try to affect the locked table, the application will become unstable (the second SaveChanges() will wait releasing the lock made by the first SaveChanges()). If such scenario happens, the application will not respond until CommandTimeout elapsed. Different versions of dotConnect for Oracle have different default value of CommandTimeout: it was 30 seconds in earlier versions, and it is 0 (unlimited) in the latest 5.35.79 version.