Use of Singletons

[Kevin Anderson]

Hi, Group:

I posted an issue a few weeks back regarding a problem where, intermittently, dependencies were not getting injected (or appeared not to be). System would run fine, for some time, then suddenly, calls to dependencies would begin failing saying the object did not exist.

Several people responded with statements to the effect that I was injecting (through property injection), objects that were not singletons and that could be causing the problem.

That creates, for me, the question as to “what” so be defined as a singleton so as to avoid the issue. Is there a “rule of thumb” on this? We are refactoring all our models and services to remove the singleton attribute from the component definition.

Any responses would be appreciated.

Kevin S. Anderson

Software Engineer

[Matt Quackenbush]

Singleton: Instantiated once for the life of the application. Contains ZERO data specific to a single user (i.e. it's for general purpose functionality, not for a particular user).

That's the rule.

Many things fall into the category of being a singleton. Anything that is specific to a user - or a request (which is inherently specific to a single user), however, is *not* a singleton, and if used as a singleton will cause untold problems.

HTH

--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/14BFE873-4C8D-457A-B62C-5C9FFD836371%40issinc.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Clausen]

Stateless and/or static.  That’s my general rule for singletons. If an object needs to change state based on data outside of the APPLICATION or SERVER scopes, extend or use a stateful object that doesn’t persist in those scopes, it doesn’t belong as a singleton.  Objects that need injected stateful objects also would be excluded.  The only injected objects I would use in a singleton would be Wirebox (which persists in the application scope) or other singletons.

Examples of objects I would use as singletons:

- File service objects (spreadsheets, images, etc.)

- Data parsing or manipulation objects

- Objects which interact with static data or assets (JSON or XML files, images which would not be updated dynamically)

- Objects which interact with or manage APPLICATION or SERVER scopes

Examples of objects I would never use as singletons:

- DAO or Gateway objects or service layers that interact with those objects

- Objects that interact with user sessions, SESSION or REQUEST scopes

HTH,

Jon