Idle connections persist after days

Idle connections persist after days

Postby jeovaalmeida » Thu 03 Nov 2011 19:03

Hello,

I'm having an issue with pending idle connection that's driving me crazy.

In most cases, the connections are closed after the pages of my web app are requested, but at the end of the day, I have about 130 pending idle connections that if not killed by our network administrator, drive to error of max connections exceeded.

I'm using Devart dotConnect with Entity Framework from dotNet 2010 and Postgresql 8.3.10

My connection string:
"metadata=res://*/Bonus.Entity.csdl|res://*/Bonus.Entity.ssdl|res://*/Bonus.Entity.msl;provider=Devart.Data.PostgreSql;provider connection string=\"User Id=user1234;Password=mypwd;Host=192.168.0.22;Port=5432;Database=mydb;Persist Security Info=True;Schema=public;Unicode=true\""
jeovaalmeida
 
Posts: 3
Joined: Thu 03 Nov 2011 18:16
Location: Brasil

Postby Shalex » Fri 04 Nov 2011 16:07

1. Tell us the exact (x.xx.xxx) version of your dotConnect for PostgreSQL. You can find it in the Tools > PostgreSQL > About menu of Visual Studio. Does the problem persist with the latest (5.50.237) version of our provider?
2. Please send us a small test project with the corresponding DDL/DML script to reproduce the issue in our environment.
3. Try setting the "Pooling=false;" connection string parameter. Does it help?
Shalex
Devart Team
 
Posts: 7774
Joined: Thu 14 Aug 2008 12:44

Postby jeovaalmeida » Fri 04 Nov 2011 20:04

Hello Shalex,

> Does the problem persist with the latest (5.50.237) version of our provider?

yes, it does persist with this latest version. I tested it with the trial version.

I'll try the 'Pooling=false' tip
jeovaalmeida
 
Posts: 3
Joined: Thu 03 Nov 2011 18:16
Location: Brasil

Postby Shalex » Mon 07 Nov 2011 11:52

Please send us a small test project with the corresponding DDL/DML script and tell us the steps we should follow to reproduce the issue in our environment.
Shalex
Devart Team
 
Posts: 7774
Joined: Thu 14 Aug 2008 12:44

Postby jeovaalmeida » Wed 09 Nov 2011 12:01

we found the problem wasn't on dotConnect.

we tweaked our data classes (transactions involved) and the connections started to close, as it should.
jeovaalmeida
 
Posts: 3
Joined: Thu 03 Nov 2011 18:16
Location: Brasil


Return to dotConnect for PostgreSQL