Comments on: Wanna Review My Code?

By: Davy Brion

Davy Brion — Fri, 26 Feb 2010 07:26:02 +0000

@Adam

true… but it also falls under the ” they’re no longer a paying customer so i no longer care about them” category

By: Adam

Adam — Thu, 25 Feb 2010 19:30:43 +0000

If CreateSessionForCurrentTenant and RemoveSessionFactoryForTenant execute at the same time with an unreasonable amount of bad luck it’s possible that Dispose gets called on the sessionfactory right before OpenSession.
I don’t see how that can be avoided without using the same lock for reading the dictionary as well.

By: Tiendq

Tiendq — Thu, 25 Feb 2010 05:20:53 +0000

I will use IDictionary and will not use {} for single IF statement.

By: Awkward Coder

Awkward Coder — Wed, 24 Feb 2010 12:31:39 +0000

I blame notepad

By: Davy Brion

Davy Brion — Wed, 24 Feb 2010 12:05:04 +0000

@Awkward

i think you got something mixed up there because that either returns an ISession or an ISessionFactory

By: Awkward Coder

Awkward Coder — Wed, 24 Feb 2010 11:57:43 +0000

plus I would change the CreateSessionForCurrentTenant to remove the other race condition…

private ISession CreateSessionFactoryForCurrentTenant()
{
lock (writeLock)
{
var tenantId = tenantContext.CurrentTenantId;
if (sessionFactories.ContainsKey(tenantId))
{
return sessionFactories[tenantId].OpenSession();
}

var connectionString = tenantInfoHolder.GetDatabaseConnectionString(tenantId);
var sessionFactory = new Configuration()
.Configure()
.AddProperties(new Dictionary
{

{ \connection.connection_string\, connectionString },

{ \cache.region_prefix\, \Tenant_\ + tenantId }

})
.AddAssembly(mappingAssemblyName)
.BuildSessionFactory();
var newDictionary = new Dictionary(sessionFactories);
newDictionary[tenantId] = sessionFactory;
sessionFactories = newDictionary;

return sessionFactory;
}
}

By: Davy Brion

Davy Brion — Wed, 24 Feb 2010 11:23:27 +0000

@Awkward Coder

aha, that is indeed technically possible

By: Awkward Coder

Awkward Coder — Wed, 24 Feb 2010 11:21:03 +0000

if one thread is in the middle of executing CreateSessionFactoryForCurrentTenant – inside the lock and hasn’t yet updated the dictionary and another thread executes RemoveSessionFactoryForTenant for the same tenant id then the first if statement outside of the lock statement will return true and exit the method, whilst the other thread completes and updates the dictionary with the new SessionFactory.

Chances of this actually happening are zero though.

or I could be complete wrong, it’s been known

By: Davy Brion

Davy Brion — Wed, 24 Feb 2010 08:59:50 +0000

@Ken

if i use the SyncRoot, i have to use it for each access to the dictionary

@JeroenH

it’s a copy-on-write implementation… reading from the dictionary is thread-safe, as long as no other thread mutates the state of the dictionary. when a ISessionFactory needs to be added to or removed from the dictionary, i create a new one, add the new sessionfactory to it or remove the old one from it, and then replace the field that holds the dictionary. during this entire operation, any other thread can still safely perform the read since the field that is used by the thread always references a dictionary that is never mutated.

@Awkward Coder

sessions aren’t stored in the dictionary… they’re sessionfactories. i don’t _think_ there’s a race condition between creating a new one, and removing one from the dictionary but i definitly could be wrong… creating and removing is both done within a lock on the same object, so i think it’s safe… if i’m wrong there, i’d really appreciate you pointing out what i missed

@Pho

you are correct about the bug
normally, it shouldn’t occur because by the time we need to remove a tenant, the users of that tenant shouldn’t even have access to the application anymore. and even if they did still have access, they’re no longer a paying customer (hence the removal of the tenant) so any exception they run into isn’t really something i’d be worried about

By: pho

pho — Tue, 23 Feb 2010 20:19:00 +0000

my refactorings based on 2 minutes of apathically staring at this code:
1. rename method CreateSessionFactoryForCurrentTenant() to EnsureSessionFactoryForCurrentTenantExists() because you’re only conditionally creating a new session factory.
2. remove the contains check in CreateSessionForCurrentTenant(). if you did this to avoid writelocks as much as possible, move the check to the method that does the actual lock. in both cases –> remove the temp variable in the public method
3. (this one is on the extremely subjective side and purely to improve readability) i’m not really a fan of implicitly adding new key value pairs and prefer using the Add(K,V) method, especially if contexts like this where you know you are adding and are certain a keyvaluepair for a given key does not yet exist.

you probably have your reasons why this isn’t already the case i guess

as for the known bug, i guess theoretically it could be that between CreateSessionFactoryForCurrentTenant() and the actual dictionary lookup, the key value pair for the current tenantid is already removed? won’t happen though.

By: Awkward Coder

Awkward Coder — Tue, 23 Feb 2010 19:33:26 +0000

@Stefan – that’s not the problem…

By: Stefan

Stefan — Tue, 23 Feb 2010 17:50:35 +0000

@Akward,

He repeats the check inside of the lock also…

By: Awkward Coder

Awkward Coder — Tue, 23 Feb 2010 17:50:32 +0000

Not that I think the it would happen in reality…

By: Awkward Coder

Awkward Coder — Tue, 23 Feb 2010 17:28:35 +0000

Isn’t there a race condition between creating & removing a session?

You could be in the middle of assigning the new session into the dictionary (which you replace everytime) and you request the (new) session be removed but it won’t be cos you’re checking outside of the lock in the remove…

By: JeroenH

JeroenH — Tue, 23 Feb 2010 16:54:30 +0000

Why do you replace the sessionFactories dictionary with a new copy every time you need to add or remove a new SessionFactory?

By: Ken Egozi

Ken Egozi — Tue, 23 Feb 2010 16:24:27 +0000

just a couple of points:
1. in RemoveSessionFactoryForTenant() you do a “reverse if” – return if the post-condition is ok, otherwise do the work, while in CreateSessionFactoryForCurrentTenant() you go the other way around, which adds an annoying nesting level. I’d reverse the if on CreateSessionFactoryForCurrentTenant() also
2. I’d also move the first Contains check into CreateSessionFactoryForCurrentTenant(), for two reasons:
i) will make the main method clearer
ii) will make it clear that we follow the two-phase check
3. question: why use an external lock object, and not the .SyncLock of the dictionary?