By Larry Caylor - 11/14/2013
I’m getting a random error when saving via the Enterpriseserver. I have a form with 5 business objects and there are parent childrelationships. I’m saving these objects using the form save method on a transactionand every so often the transaction fails (see attached screen shot). If Iremove the transaction and simply save by form, it works 100% of the time. If Ibypass the Enterprise server and use a direct connection, both save by formwith and without a transaction works 100% of the time. There is something aboutsaving on a transaction via the Enterprise server that is randomly failing. TheSQL box is the same system for both the direct and Enterprise connections andthe number of pools is set to the default of 100. And suggestions?
|
By Trent L. Taylor - 11/14/2013
How long is it taking before you get the error? Also, how many records are you saving (roughly)?
|
By Larry Caylor - 11/14/2013
What the application is doing is building an appointmentcalendar with preconfigured time slots and writing the appointment records outto the database. The application is using the Infragistics WinSchedulecontrols. Each appointment record can be up to 2600 bytes (the calendarcontrols require a 2048 variable binary field) in addition to the other fieldsin the record and there can be anywhere from a couple of hundred records tothousands depending on the time period that the calendar covers. In one of thetests I ran there were around 600 records. When I ran the save using ES withouta transaction it completed in a couple of seconds. When I ran it on atransaction it failed at around 35 seconds. In general it’s the larger numberof records where I see the problem, but it’s not consistent.
|
By Larry Caylor - 11/14/2013
Sorry for all the typos. Looks like pasting from Word messes up the format.
|
By Larry Caylor - 11/15/2013
To simplify things I created a test application that eliminates my inherited business layer and cuts the number of business objects down to two. What I've found out from running the test application and looking at the database server is that it appears that when saving on a transaction, the ES server tries to obtain one pooled connection for every record. The parent/child relationship doesn't make a difference. If I have 99 parent records and 0 child records everything works fine. But when the parent record count exceeds the maximum number of pooled connections (100 on my server), the save will likely fail and the failure happens when the connection timeout is reached, which I've configured to be 45 seconds. I say likely because 101 may eventually save but 200 will always fail. When there are both parent and child records, the error begins to occur when the total record count exceeds 100.
|
By Larry Caylor - 11/19/2013
Any update on this?
|
By Larry Caylor - 11/25/2013
??????
|
By StrataFrame Team - 12/3/2013
Sorry for the delay, Larry. I was out on vacation when you posted your first question and Trent was holding down the fort. Then, I was up-chucking all Thanksgiving week.
You're not the first person to get this error. We have seen it ourselves. It's a bug in the ES that we have resolved in the past. When you save on a transaction, the connection never gets disposed/cleaned up properly, so the connection never gets returned to the pool. After you've used 100 SqlConnection objects to save on transactions, the next time the ES tries to get a connection from the pool when it creates the SqlConnection, you get that exception. I don't remember specifically which assembly the fix was in. It might have been in Base or Enterprise. I will setup a test tomorrow and go through the old versions to reproduce it and figure out which assembly you need for the fix.
|
By Larry Caylor - 12/4/2013
Hi Ben,
Sorry to hear your Thanksgiving wasn't that great. If it helps resolve the issue I'm running the latest version of the framework and ES. Before I posted the problem I download the manual update for ES and re-installed it on the server.
-Larry
|
By Larry Caylor - 1/8/2014
Was a fix for this ever found? I'm on version 1.7.7.7 and it's still happening.
|
By Trent L. Taylor - 1/9/2014
It should have been in your build, but let's make sure that you have the most recent assemblies. I am going to create a package file and send it to you here in a bit.
|
By Trent L. Taylor - 1/9/2014
Larry:
We are going to take a different approach here. We are going to try and replicate your scenario first and see if we can get it to fail. Once we can get it to fail then it is an easy next step to get you a solution. So give us a day or two and we are going to try and create a sample that fails in a lab setting so that we can make sure that we are on the same page. We may send you an email or two if we can't replicate it. Thanks for your patience.
|
By Larry Caylor - 1/10/2014
Trent,
Thanks for the update. I'll wait to see what you find out.
|
By Trent L. Taylor - 1/10/2014
The whole issue pertains to the transaction, I think that much as been established. But we will try and come up with a solid scenario so we can really prove it out.
|
By StrataFrame Team - 1/13/2014
Larry,
We got it fixed. The issue has existed since the beginning. Looking through our exception logs from PracticeStudio, several of our customers end up getting the issue on a routine basis. There was never any method to the madness of when the exception would occur, though. The problem was exactly like you said, we were creating a new connection and opening it in the DbDataSourceItem.ExecuteReader() method that was a local variable so it would simply go out of scope. That made it rather hard to track. The connection was used when you weren't on a transaction. It would be properly cleaned up at the end of the execution. But if you were using a transaction, the variable would go out of scope and would have to rely on the garbage collection to clean it up. That made the error rather random. If your .NET environment was GC'ing regularly, then the connections would be removed and returned to the pool without issue. But, if your application wasn't needing GCs then the pool would be consumed. We did finally find a scenario that allowed us to chew up the pool and reproduce the problem consistently, so we know that the issue is resolved. We build v1.7.8.0 and posted it on the downloads section of the My Account area. Let me know if it doesn't fix your issue.
|
By Larry Caylor - 1/14/2014
I didn't see a v 1.7.8 in the download area, but I did see v 1.7.7.1 for the framework. I didn't see any changes to the ES server. I download the new framework version and ran my test program. I still get the error when saving on a transaction. With no transaction everything works fine no matter how many records I throw at it.
-Larry
|
By StrataFrame Team - 1/14/2014
Sorry, we changed the version to 1.7.7.1 instead of 1.7.8 before it was built. That 1.7.7.1 is the right version. There were no changes to the ES. The fix was in MicroFour StrataFrame Base. You'll need to put that new Base assembly (and the others) with your ES and try it again. You'll probably need to recycle the app pool after you swap out the assemblies. We may end up needing to rebuild the ES for you, too, but I don't believe any signatures changed, so you shouldn't have any issues with MissingMethodExceptions or anything like that.
|
By Larry Caylor - 1/14/2014
I replaced the Base and Enterprise dl's on the ES server and restarted IIS. Save on transaction with >120 records still fails.
-Larry
|
By StrataFrame Team - 1/14/2014
Can you zip up your test database and test project and send them to me so I can debug it? That way I know we'll be looking at the same thing...
|
By Larry Caylor - 1/14/2014
Attached are the files. The application is a PKWare self extracting file. It's a simple program that creates some data records then allows you to save them with or without a transaction. It allows a parent child relationship to be defined but so far I can get it to consistently fail with just a parent record count > 120 and no child records.
-Larry
Edit: bchase (deleted attachments)
|
By StrataFrame Team - 1/14/2014
Thanks Larry. I'll start looking at it.
|
By StrataFrame Team - 1/15/2014
OK, Larry, I wasn't able to make your test program fail on this end. So, thinking that your test program was pretty definitive, I rolled back my ES debug version to the 1.7.7.0 version and tried it. It failed just like you said. I didn't think I had made a change, but apparently I did. Looking through our TFS logs, I found where the SqlDataReader wasn't being properly closed (which closes the connection, because the command is executed with CommandBehavior.CloseConnection since we no longer have a reference to the connection to close it). Those connections were left open and had to be garbage collected just like the other situation.
So, I have posted the ES from the build 1.7.7.1 to the My Account area as both the .zip and the complete install. Let me know how that works.
|
By Larry Caylor - 1/15/2014
Hi Ben,
That fixed it! I ran a few tests and the save on transaction is slightly faster. Thank you for your help. When you get a chance please post the 1.7.7.1 source code installer to the download area.
-Larry
|
By StrataFrame Team - 1/16/2014
Will do! Thanks for your patience while we figured that one out, Larry 
Glad we got it working.
|