Anything wrong with this?

ajj3085 posted on Friday, May 30, 2008

Hi,

I pushed an update of my application to production.. and of course there was a major problem with it.  It only happens when remoting is enabled, so my band-aid is that I now have remoting turned off.

I have a singleton pattern whcih loads from the database.  The instance is created like this:

        internal static RoleGroupMapper Mapper {
            get {
                lock ( lockObj ) {
                    if ( instance == null ) {
                        instance = DataPortal.Fetch<RoleGroupMapper>();
                    }

                    return instance;
                }
            }
        }

Now, this seems to work ok.. except that this code would bomb:

        internal IList<string> this[ string roleName ] {
            get {
                return roleMappings[ roleName ];
            }
        }


Now, for some reason roleMappings exists, but seemed to always be empty.  I can't figure out how that would happen..

Turning off remoting solves the problem.  Any ideas what could be wrong?

The indexer property is used both on client and server.

Thanks
Andy

RockfordLhotka replied on Friday, May 30, 2008

Implementing a singleton that is used on the app server can be problematic - specfically because the app server is multithreaded, and you could easily have mutliple threads interacting with that one object at the same time. Unless you take steps, your object is probably not threadsafe. Certainly any manipulation of a collection is unsafe unless you have appropriate locking code around the collection.

ajj3085 replied on Monday, June 02, 2008

I was able to figure out what the issue was.  The collection itself cannot be changed; the singleton, once created can only be read, not changed.

The problem was stupidity on my part; I launched the application after creating the tables from which my singleton reads, but before I had filled it with any data.  Of course, the code which uses the singleton assumes that roles is asks about ALWAYS exist in the indexer.

I ended up redeploying the application, which of course caused the Asp.Net hosting process to restart, and this time when the application started the data was there, and so it worked just fine.

So... the problem was I was rushing to deploy, and didn't finish doing the database updates before I tried starting my application.. which is exactly the reason I built code to keep  users out when I set a flag!