Applied, thanks. If you don't mind, please create a test that fails for the behavior prior to the patch. This ensures that future changes don't reintroduce the error.
-Markus 2009/1/16 Tyler Burd <[email protected]>: > 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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
