Yes, I'm actually seeing that myself trying out various scenarios. I have a definite need for this to work in my current project, so I'm going to take a close look this weekend and see what, if anything, I can figure out.
Thanks, Tyler ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of David N. Godfrey Sent: Monday, January 19, 2009 3:35 AM To: [email protected] Subject: RE: DifferentDatabaseScope bug & patch I don't remember all the details but it was mostly nesting different combinations of scopes within each other to see what worked and what didn't. I do remember that the symptoms could change depending on whether the outer scope had been accessed before the nested scope was created. Dave. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Tyler Burd Sent: 16 January 2009 15:47 To: [email protected] Subject: RE: DifferentDatabaseScope bug & patch I can definitely see that. All the existing tests pass with my patch, so I don't think I've broken any previously-working scenario. If you recall what some of the other issues were I'd be happy to toy around with things and see if I can help. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of David N. Godfrey Sent: Friday, January 16, 2009 5:47 AM To: [email protected] Subject: RE: DifferentDatabaseScope bug & patch I had a look at this a while ago and noticed a few oddities in behaviour when mixing SessionScope, TransactionScope and DifferentDatabaseScope depending on which was nested inside the other. I could make individual scenarios work but always at the expense of a different one - I never managed to make them all work. In the end I left it and decided not to mix DifferentDatabaseScope with the others. Dave. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Tyler Burd Sent: 15 January 2009 23:44 To: [email protected] Subject: DifferentDatabaseScope bug & patch My team has been running into a problem when using DifferentDatabaseScope. I have attached a patch that fixes the issue, but let me describe the issue first... When using DifferentDatabaseScope in the following manner: using (var s = new SessionScope()) { IDbConnection conn1; //initialize and open conn1 using (var diffScope1 = new DifferentDatabaseScope(conn1)) { } conn1.Dispose(); IDbConnection conn2; //initialize and open conn1 using the *SAME* connection string as conn1 using (var diffScope2 = new DifferentDatabaseScope(conn2)) { } conn2.Dispose(); } We started to see all kinds of "connection already closed/disposed" errors in the second DifferentDatabaseScope. I tracked the problem down to the Castle.ActiveRecord.Framework.Scopes.KeyHolder class and the DifferentDatabaseScope.GetSession method. GetSession looks up a session using a key that is composed of a connection string and a few other items. The problem is that the keys for conn1 and conn2 are the same, so all operations in the second scope were trying to use conn1. My patch adds the hashcode of the connection to the KeyHolder class, so that connections can be distinguished even when they have the same connection strings. This is probably not bullet proof either, but in my tests (PostgreSQL and SQL Server) it works like a charm. I would be happy to create an issue to document this patch, but I wanted to put it out there first to make sure it's not something that someone's already aware of. -Tyler <BR <BR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
