Singleton Session pattern achieves readability of the code and possible use of Java's inheritance and abstraction to define and access variables in the Singleton-based application or Framework like Struts for example. In Struts each Action is istantiated only once and is reused than across the life of the context (until restart and reload), therefore all of the variables that are necessary to be passed to a method of a custom action need to be defined localy and passed to the method from the execute method. Instead one can create an "session" class with getObject(Object key) and setObject(Object key, Object obj) methods and define all of the necessary variables/objects using those two methods and pass only the instance of the "session" class to all of the necessary methods. "session" class can be strongly type, eg.:
<br>
public class StrongTypedSingletonSession {
<br>
 private String a = null;
 private String b = null;
 private String c = null;
<br>
 public void setA(String a) {<br>
   this.a = a;<br>
 }
<br>
 public String getB(String b) {<br>
   this.b = b;<br>
 }
<br>
 public String getC(String c) {<br>
   this.c = c;<br>
 }
<br>
 <br>
 public String getA() {<br>
   return this.a;<br>
 } <br>
<br>
 public String getB() {<br>
   return this.b;<br>
 }
<br>
 public String getC() {<br>
   return this.c;<br>
 }
<br>
}<br>
<br>
In this example you know before hand what objects you need to set and access, including those object's types.<br>
<br>
It could also be weakly-typed, eg.:<br>
<br>
public class WeaklyTypedSingletonSession {<br>
 private Map objects = new HashMap();<br>
<br>
 public void setObject(String key, Object obj) {<br>
    synchronized(this.objects) {<br>
      this.objects.put(key, obj);<br>
    }<br>
 }<br>
<br>
 public Object getObject(String key) {<br>
   Object obj = null;<br>
   <br>
   synchronized(this.objects) { <br>
     obj = this.objects.get(key);<br>
   }<br>

   return obj;<br>
 }<br>
<br>
}<br>

This example let's you define any number of objects of any type, letting the custom part of the application to decide which particular objects it needs.

This pattern helped me quite a bit when I have enabled the framework that I wrote with Struts, so my frameworks modules could be accessed over the web and benefit from Struts features. My framework itself is detached from any specific access method (web, standalone and etc.), but plugins of it would for instance use request and response objects available via Struts Action, which I would define, along with other objects like action mapping and action form in a weakly type Singleton Session and pass it to my class ensuring flexibility and type abstraction.

The DTO pattern is used to pass information from the client tier (i.e. web tier in the case of Struts) to the business logic tier (such as remote EJBs). Isn't your pattern essentially the same thing. Your "session" class should also implement Serializable since the DTO could be transferred to a remote EJB.

- Jeff

That is true in case you tie your pattern to the EJB implementation and do not think about abstraction and code reusability outside of a specific implementation itself.

I wish pattern-invention-challenged ones used the classical GoF format for definitions of patterns. Isn't it humorous that this "pattern" promoting "readability of the code" is unreadable itself?

Not to mention that sticking into a session ever-growing HashMaps is poor design and is the number one source of memory leaks.

Being so adamant about the GoF format, why wouldn't you offer a direction backed up by a set of concrete examples on how such a pattern definition would look like.

In case of HasMaps, if you have your code written without keeping garbage collection and general object cleaning in mind, that would be the major source of memory leaks, otherwise it works just fine as long as you clean up unused objects at the end of the session, which in itself can be an abstracted mechanism, that a given user-developer would not worry about.

And again, given your judgement on poor design, what would be a good design as far as you are concerned? Being a critic is always easier especially if you do not have facts that back your criticism.

Artem,

A class that wraps a HashMap with synchronized access methods is not a pattern. It's a Hashtable. I really don't see anything here that has to do with patterns whatsoever and I don't see any ground for discussion here either.

If you haven't read the GoF book - may be it's time to do so. It's a good reading anyways.

Regards,

Slava Imeshev

Slava,

I agree GoF is a good reading, thanks for THAT suggestion...

As far as Hastable...did you read the first part of the pattern???

Or you are just concentrating on the second part???

What if I have methods that do a certain type of data conversion or translation, let's say

"1" to 1(int) -> getInt(...)...or "^[A-Z]{8}" to java.util.regex.Pattern -> getPattern(...). Would you consider Hashtable fitting such requirements? What if you want to retain control on your syncronization logic? What happens then?

The recommended approach is to use HashMap as it does not force you to go the sycnrhonized rout at all times, I did use it in my example, though one might not want to use such as well as not even use the HashMap, that was just an example of name/value storage...

Think as far as flexibility, not as far as predefined constraints...You want to have as much control over your code as possible while still making it lightweight...

And to summarize, what is a pattern? Do YOU have a definition? (Besides a set of GoF patterns...)


Cheers,

Art Yegorov

I would agree though that the way the definition is with all the <br>s and lack of indentation and otherwise any distinction between components, it is pretty unreadable...

Well, my first post...

Tough luck I guess...

I wish pattern-invention-challenged ones used the classical GoF format for definitions of patterns. Isn't it humorous that this "pattern" promoting "readability of the code" is unreadable itself? Not to mention that sticking into a session ever-growing HashMaps is poor design and is the number one source of memory leaks.

Slava,

HashMaps usage by itself is absolutely NOT a source of memory leaks. What on earth are you referring too?

I really do not see any inheritance and abstraction code here. Also this is the first time i am seeing a pattern using "synchronized" code. Please do not post anything that you write in your code with the title "pattern".

Thanks,
Vikas.

Maybe it is a first time you see a pattern?

How about you criticize with a solid example behind your back, otherwise all you say is just fluff! So please do not post any of the fluff you are accounted for here.

Thanks,

Art

This "pattern" looks horribly similar to using global variables in certain ancient languages.
On the other hand, what's the dessign issue it addresses? Has it ever been used, tested and accepted as a good solution... more than once, for more than a single scenario?
Perhaps I'm not undestanding some critical aspect of it. At first sight, it seems that having an access-it-wherever-you-are object "bag" (or, more formally, what some technologies call a "context" or "environment"), is due to some design flaw... That's not the point of the singleton pattern.
So, I'd rather recathegorize this approach as an anti-pattern:
"DO NOT use a global repository when you don´t know how to communicate your components. Please check your collaboration diagrams."
...because whe use and love those, don't we?
I do have a solid example to back my words up: that's exactly what happens in the vely "grande" J2EE project I'm currently working. Lots of this data bags like this scattered through the layers. It's nothing but a mess. Too much code to paste it here, though.
Plus, there's no need to provide an alternate solution to something that should have never seen daylight, anyway.

PS: Artem, please don't feel offended when someone doesn't share your view on things. Being wrong is the best way to learn; being stubborn doesn't help at all.

Regards,
Martin

I would agree to those people here who say that it's not a pattern at all...
"don't pass <x> single objects but put them into one"... this is the idea of a bean...