current transaction is aborted, commands ignored...

current transaction is aborted, commands ignored...

Postby Deepak » Thu 22 Jun 2006 17:23

I often get this error with the connectionpooling set to true...
current transaction is aborted, commands ignored until..
however when i change it to false the error vanishes. I need to have the pooling on

any suggestions?

thanks in advance
Deepak
 

Postby Alexey » Fri 23 Jun 2006 06:34

Please describe the problem in detail.
Send us small test project if possible to reproduce the problem; it is
desirable to use 'test' schema objects, otherwise include definition of
your own database objects. Do not use third party components.
If it is impossible for you to create test project please send us a piece of
your code where the error occurs.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Zoran » Wed 21 Mar 2007 21:53

We have the same problem, using Win 2003, 8.1+ versions of Postgres and Corelab driver 2.55.
I assume that the problem starts when there is an aborted transaction, like when trying to insert a record with existing PK, and no rollback or commit follows. That connection is returned to the pool and new clients start using it, in aborted state. If there are 20 connections in the pool, the effect is that random 5% of requests for a fresh connection return the error in the title.
I suppose that this behaviour is not normal since I would expect to get a connection from the pool with no previous client's state.
I could not find a way to detect the rogue connection when requesting a fresh one. There is no connection's property saying if it is in transaction state. I tried writing some other data to the in-transaction connection (like specific timeout), but it is not available after recycling (that behaviour is correct).
The solution we use is to rollback every new connection and that solved the problem in a not so elegant way.
Zoran
 
Posts: 44
Joined: Thu 28 Apr 2005 21:55
Location: Zagreb, Croatia

Postby Alexey » Thu 22 Mar 2007 08:05

Please send me a small test project to reproduce the problem. It is
desirable to use 'test' schema objects, otherwise include definition of your own database objects.
Use e-mail address provided in the Readme file.
Do not use third party components.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Zoran » Sat 24 Mar 2007 08:13

Is it not easy to make a small project. We use our own framework with meta-generated C# code. I am afraid it will take days to extract a small project from that all. Besides, I've never seen that message on my development PC. I suppose I should have tried simulating a bigger workload. However, our production web servers used to report 50+ such error messages daily before rollback-all cure was used. After that single line was added, no such message has ever been reported.
We do not use third party components. Not even MS server controls.

Now, we open connections like this (notice Rollback):
...
if (cn==null)
cn = new PgSqlConnection(connectionString);
cn.ConnectionTimeout = connectionTimeout.Number;
cn.Open();
cn.Rollback();
...

Connections' destructor includes:
...
cn.Dispose();
...
We tried .Close() but it did not help. I suppose that only an explicit call to a GC would solve the problem, but also by removing performance advantages of the connection pool.
Zoran
 
Posts: 44
Joined: Thu 28 Apr 2005 21:55
Location: Zagreb, Croatia

Postby Alexey » Mon 26 Mar 2007 15:40

We are investigating this problem. I'll let you know our progress.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Alexey » Tue 03 Apr 2007 10:50

This problem is fixed. Look forward to the next build.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Alexey » Tue 24 Apr 2007 07:28

PostgreSQLDirect .NET 2.55.26 is available for download now. Please check it out.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Paulblo » Fri 27 Apr 2007 17:44

I was having the same problem as this in the version 2 of the library, and just upgraded to vbersion 3. Did this bug only exist and get fixed in version 2?

I am now running PostgreSQLDirect .NET Standard version 3.00.8 (13.04.07) and will be testing it to see if the same problem occurs.
Paulblo
 
Posts: 1
Joined: Fri 27 Apr 2007 17:09

Postby Alexey » Sat 28 Apr 2007 06:22

This bug should be fixed in the latest version.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Postby Zoran » Wed 09 May 2007 09:31

I tried to use version 3.0 but I got the message "Could not load type CoreLab.Common.DbConnection from assembly CoreLab.PostgreSql, Version=3.0.8.0,..." when trying to open a connection.
So, I cannot test it. I use .Net 1.1 version and Windows 2003.
Zoran
 
Posts: 44
Joined: Thu 28 Apr 2005 21:55
Location: Zagreb, Croatia

Postby Alexey » Thu 10 May 2007 07:18

Try to reinstall PostgreSQLDirect .NET.
Make sure that PostgreSQLDirect .NET isn't installed and there are no old
CoreLab.* assemblies in the GAC.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Could not load type CoreLab.Common.DbConnection

Postby Zoran » Mon 14 May 2007 06:36

I tried several times. The procedure was like this:
1. Uninstall 2.5* version.
2. Restart
3. Install 3.0 version
4. Restart
After the step 4 \Windows\assembly shows:
...
CanManServer
CoreLab.Data 4.0.8.0
CoreLab.PostgreSql 3.0.8.0
cscompmgd
...
Zoran
 
Posts: 44
Joined: Thu 28 Apr 2005 21:55
Location: Zagreb, Croatia

Postby Alexey » Mon 14 May 2007 08:12

Seemingly, you have installed PostgreSQLDirect for .NET2.0 and are trying to use it with .NET1.1 framework. Please check this carefully.
Alexey
 
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

.Net 2.0 Version

Postby Zoran » Tue 15 May 2007 09:26

I downloaded the 1.1 version twice and did so again now, using "PostgreSQLDirect .NET Professional for .NET Framework 1.x [size 3218 Kb]" and downloaded exe really has 3219 KB, not 3434 KB.
Zoran
 
Posts: 44
Joined: Thu 28 Apr 2005 21:55
Location: Zagreb, Croatia

Next

Return to dotConnect for PostgreSQL