Singleton

  • Thread starter Thread starter solex
  • Start date Start date
S

solex

Hello,

I am trying to model a session object that is essentially a collection of
different items (connection string, user name, maps etc.) I would like this
session object to be available to other objects within my client
application.

I can do one of two things (1) make the session object a singleton (2) pass
the session object to the methods that need them. Option 2 is a bit more
complicated and messy then option 1. My other goal in this excercise is to
be able to reuse these other objects within a web or application or server
environment, a singleton object would, I believe limit my scalelability and
perhaps not work at all because what I really need is an session singleton
per user session.

Any comments on how I might achive option 1 in a Web environment so that I
can reuse the other objects?

Thanks,
Dan
 
Hi Solex,

My first thought would be a singleton SessionCollection object which
provides access to the individual Session objects.

My second thoughts will come when you tell me it won't work for you. ;-)

Regards,
Fergus
MVP [Windows Start button, Shutdown dialogue]
 
Solex,
I would implement it externally as a singleton, however internally I would
use a Strategy Pattern, possible app.config/web.config based that indicated
to use a private shared field for the backing store or the
HttpContext.Session or a ThreadStatic variable.

See the following on how to create new sections in the app.config/web.config
via the configSections section.

http://msdn.microsoft.com/library/d...de/html/cpconconfigurationsectionhandlers.asp

and:
http://msdn.microsoft.com/library/d...ref/html/gngrfconfigurationsectionsschema.asp

Also read about the System.Configuration.ConfigurationSettings class and
other classes in the System.Configuration namespace.

Hope this helps
Jay


Hope this helps
Jay
 
Jay,

Thanks for your response, the App.config may work for applications settings
but will not work for user settings which may change during app execution.

The strategy pattern is an interesting idea where the Context Object would
be implemented as a Singleton. But is it possible to create a singelton
within the context of a single session. What I really need is for every
session to create its own Session object to be used by the other objects. I
cannot use a singleton that is global to the application on the Web side.

Thanks,
Dan
 
solex,
Thanks for your response, the App.config may work for applications settings
but will not work for user settings which may change during app execution.
Click to expand...
No no no. (hangs shaking head muttering)

The app.config is used to decide which strategy to use by the MySession
object it has nothing per se do with runtime application settings or user
settings!

Remember app.config is for application settings used at start up. It should
not be used for user settings. Especially that change during app execution,
as app.config is for startup information!
session to create its own Session object to be used by the other objects. I
cannot use a singleton that is global to the application on the Web side.
Click to expand...
Yes you can! Let me try to explain what I stated, as what I stated may not
have been very clear.

The easiest way for me to explain other than what I previously stated is an
example:

Untested, non syntax checked VS.NET 2003 sample:

Public NotInheritable Class MySession
Inherits DictionaryBase

#Region " Singleton Support"

' note the use of the strategy variable, not an instance variable
' this is where I stated 'internally I would use'
Private Shared Readonly m_strategy As MySessionStrategy

Shared Sub New()
' use app.config/web.config to determine the strategy
Dim strategy As String =
ConfigurationSettings.AppSettings("sessionStrategy")
Dim type As Type = Type.GetType(strategy)
m_strategy = DirectCast(Activator.CreateInstance(type),
MySessionStrategy)
End Sub

' Needs to be friend as the strategy may create instances
Friend Sub New()
End Sub

' note the instance property looks like a normal Singleton
' but the strategy actually defines the behavior
' this is where I stated 'externally I would use'
Public Shared Readonly Property Instance() As MySession
Get
Return m_strategy.Instance
End Get
End Property

#End Region

Default Public Property Item(ByVal key As String) As Object
Get
Return InnerHashtable(key)
End Get
Set(ByVal value As object)
InnerHashtable(key) = value
End Set
End Property

' and other 'session' level methods.

End Class

Friend MustInherit Class MySessionStrategy

Public MustOverride ReadOnly Property Instance() As MySession

End Class

Then you need to implement a different MySessionStrategy class for ASP.NET
apps, Windows Services or Windows programs. Where the strategy decides how
to store the Instance data safely for each of these type of programs.

If you wanted to support both Application & Session like variables you can
add more methods to MySessionStrategy and implement them there. The
MySession object would have shared methods that then delegated to the
MySessionStrategy versions.

Rather than have sessionStrategy in appSettings, I would actually create a
custom section that is specific to the library where MySession is
implemented. I would more than likely implement MySession in its very own
class library assembly! (as the constructor is Friend and it needs to be
protected, the other option is to make MySessionStrategy nested inside of
MySession, giving it the ability to create a new MySession if the derived
classes need to...

No matter the type of program you use it like a normal singleton

MySession.Instance("bla bla") = 100

The strategy actually decides how the data is stored nicely for each
'session'.

Hope this helps
Jay
 
Jay,

Thank you for your detailed example. Sorry but I have a few more questions:

(1) First and foremost is when using a singleton in a web environment does
this not mean that for every request everyone will be getting the same
instance of MySessionStrategy?

(2) Also what is Instance supposed to return in MySessionStrategy?

Thanks,
Dan
 
Dan,
(1) First and foremost is when using a singleton in a web environment does
this not mean that for every request everyone will be getting the same
instance of MySessionStrategy?
Click to expand...
Correct, there will only be one instance of any strategy. Remember the
MySessionStrategy is a Strategy of how to store session data it is not the
mechanism to store that data!

By that I mean a Web App, would use the WebSessionStrategy which might be
based on HttpContext.Session.

While for a Windows Forms app would use the FormsSessionStategy which might
be based on shared variables.

Of course you can define the actual strategy however you want for each
environment.
(2) Also what is Instance supposed to return in MySessionStrategy?
Click to expand...
Per the definition I gave it is suppose to return a MySession object.

How that object is persisted between calls to the method is what YOU need to
define!

For a windows forms application which are inherently are single user, where
is the best place to store 'session' information? I would use a shared
field.

For an ASP.NET application which are inherently multiuser, where is the best
place to store 'session' information? I would use a HttpCOntext.Session
field.

I'm leaving the actual answer to this question to you, as you have a better
idea of what you are attempting.

Going back to your original post, you want to be able to store "session"
data independent of the platform. Am I misunderstanding what you are asking?

Hope this helps
Jay


solex said:
Jay,

Thank you for your detailed example. Sorry but I have a few more questions:

(1) First and foremost is when using a singleton in a web environment does
this not mean that for every request everyone will be getting the same
instance of MySessionStrategy?

(2) Also what is Instance supposed to return in MySessionStrategy?

Thanks,
Dan
Click to expand...
<<snip>>
 
Dan,
I should add to my previous post.

The MySession singleton is giving your application a common API to use to
get to 'session' data, while the MySessionStrategy is giving your
application the felicity to define how best to persist that 'session' data
between calls taking into consideration multiple users & threads...

Hope this helps
Jay

solex said:
Jay,

Thank you for your detailed example. Sorry but I have a few more questions:

(1) First and foremost is when using a singleton in a web environment does
this not mean that for every request everyone will be getting the same
instance of MySessionStrategy?

(2) Also what is Instance supposed to return in MySessionStrategy?

Thanks,
Dan
Click to expand...
<<snip>>
 
Jay,
Going back to your original post, you want to be able to store "session"
data independent of the platform. Am I misunderstanding what you are
Click to expand...
asking?

No, you hit the nail right on the head and I appreciate you input!

I was having a trouble getting my head around the fact that
MySessionStrategy was creating its own instances of the singleton MySession
and that MySession is going to be delegating to the Instance of
MySessionStrategy that created it I will need to try an implement this and
will need to get back to the you and the group.

Thanks Again,

Dan
 
application the felicity to define how best to persist that 'session' data
between calls taking into consideration multiple users & threads...
Click to expand...

I would like MySession to use the HTTPContext.Session to both read and write
the data.
 
Hi Solex,

I've briefly looked through what you and Jay are discusing but I'm tired
this weekend and haven't the brain power to study that track properly :-(

I'll therefore answer independantly of that track with some second
thoughts on this one - again very superficial. ;-) so you might want thirds.
[That, or to tell me where to get off, lol.]

The problem is that you don't want the OBs to have to know who their
Session is - so a Session in a Collection has the same problem as an
independant Session floating around?

How about if you reverse the 'ownership'? Then, each Session knows which
OBs it's working with. In the sense of a handle except that you don't want
your OBs to need a handle (same issue). The handle, however, could be an
elected representative of the OBs or some other unique property that the group
already possesses. This does, of course, assume that the OBs <have> a common
element.

Then, when the Session is first created, it is told with which OB set it
is to work. The SessionCollection would be given this when access to the Ob's
Session is required.

You may have already gone with Jay's Pattern. I couldn't tell. :-)

Regards,
Fergus
 
Back
Top