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
current transaction is aborted, commands ignored...
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.
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.
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.
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.
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.
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.
Could not load type CoreLab.Common.DbConnection
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
...
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
...
.Net 2.0 Version
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.