[
http://tracker.firebirdsql.org/browse/DNET-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Cincura reopened DNET-87:
------------------------------
OK, I see the point. I'll re-fix it this week.
> Error invalid transaction handle
> --------------------------------
>
> Key: DNET-87
> URL: http://tracker.firebirdsql.org/browse/DNET-87
> Project: .NET Data provider
> Issue Type: Bug
> Components: ADO.NET Provider
> Affects Versions: 1.7.1, 2.0, 2.0.1 RC 1, 2.0.1 RC2, 2.0.1, 2.1.0 Beta 1,
> 2.1.0 Beta 2, 2.1.0 Beta 3
> Environment: Firebird Superserver 1.5.3.4870
> WinXP SP2
> Reporter: Ralf Giese
> Assignee: Jiri Cincura
> Priority: Critical
> Fix For: 2.5.0 Alpha 3, 2.5.0
>
> Attachments: Demo.cs
>
>
> We've developed a client-server application using .NET Data Provider
> 1.6.3 in the data layer of the server. Each client has a separate
> data access object on the server and is calling it via .NET Remoting.
> The application worked fine in a production environment with about 12
> clients for several month's. Then I updated the data provider to v2.0.
> After a timespan from some hours to some days one of the data access
> objects began to return IscExceptions, mostly "invalid transaction
> handle (expecting explicit transaction start)", on almost all following
> calls until the server was restarted. No changes with implementing
> data provider v1.7.1, so I had to go back to v1.6.3.
> I built a test environment and tried to reproduce and debug the error.
> Each data access object of my application contains a common
> FbConnection object and some FbDataAdapters with FbCommands for
> multiple use. There are procedures using temporary FbCommands too,
> e. g. each call creates a new FbCommannd object with the common
> connection object. There's no explicit Dispose() for those commands,
> so disposing should be done by garbage collector later. At the end of
> each call to the data access object the common connection will be
> closed for further use in the connection pool.
> In normal operation state FbConnection.Close() releases all prepared
> commands and removes them from inner connection. I found, that in error
> state FbConnection.PreparedCommands doesn't contain the FbCommand
> object that rises the exception during FbCommand.Execute(). So this
> command isn't released and if it is used again subsequent it has still
> an (unvalid) prepared GdsStatement. The GdsDatabase of this statement
> meanwhile can point to an inner connection of the connection pool that
> is closed or used by another thread. Calling GdsStatement.Execute() on
> such an unvalid statement rises an IscError.
> But why PreparedCommands dosn't contains the command when closing
> connection? When garbage collector disposes an FbCommand object with an
> open FbConnection object, it calls
> FbConnectionInternal.RemovePreparedCommand() in FbCommand.Release().
> In RemovePreparedCommand() the garbage collection thread calls
> PreparedCommands (get) and can cause a conflict with an application
> thread there. Sometimes the application thread creates a new ArrayList
> for prepared commands and adds the first command. After that the
> garbage collection thread creates a new empty ArrayList and replaces
> the ArrayList with the new command.
> I checked csv for .Net Data Provider v1.6.3. There's a
> GC.SuppressFinalize() in the constructor of the FbCommand class.
> Therefore no errors occur in that version.
> I added a explicit Dispose() to each temporary FbCommand and no further
> errors occured. Is this the recommended way to use FbCommand? I think
> it would be useful to modify the provider to prevent that garbage
> collection threat can reach code that is still executed by application
> threads.
> A simple test application is attached. The number of required cycles to
> get the first error vary depending from used machine. On WinXP-SP2
> workstation with Pentium 4 HT 3.2 GHz I needed up to about 50000 cycles
> (2 hours). On a second machine with Pentium 4 2.2 GHz (without hyper
> threading!) I got first error after about 150 cycles (40 seconds) yet.
> To gain the effect on the first mentioned machine I temporary modified
> FbConnectionInternal:
> -----
> // next line for test only
> Random delayRadom = new Random();
> public ArrayList PreparedCommands
> {
> get
> {
> if (this.preparedCommands == null)
> {
> // next 2 lines for test only
> int delay = delayRadom.Next(2);
> System.Threading.Thread.Sleep(delay);
> this.preparedCommands = new ArrayList();
> }
> return this.preparedCommands;
> }
> }
> -----
> With this changes error occured on first machine after about 50 cycles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Firebird-net-provider mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
