My persistency mechanism is one object (storage) per datasource. So the storage is not really a singleton, but a storage on a specific datasource is a singleton.
I use an entity bean, with PK string. In the home interface there (only) is a findByName(String name). Everytime i need the storage of a certain datasource, i find the entity bean using it's name. In the find implementation, i lookup/rceate the singleton in a static mapping from names to storages.
The persistency is bean managed, the load/store implementations are empty, and the getByPrimaryKey simply returns the name given as parameter. The entity bean is reentrant, transactions are container managed.
I think this is a way to make multithreaded singleton EJB's. The pattern I found once it a j2ee patterns book talked about manually mapping objects in jndi. I think my idea is easier, but i'm not sure of the full consequences.
What do you think?
I'm not exactly sure what you mean to accomplish using this entity bean. Is it supposed to be a singleton? If so, it isn't. Depending on the concurrency management algorithm used by the container, your bean may or may not be instanciated multiple times with the same PK, as a result of multiple transactions. Generally commit options B and C would allow such situations.
I think there is another problem, but I'm not sure I understand your goal yet. Could you throw some light on possible usgae scenarios or list some sample code?
commit options B and C, what do you mean?
my goal: i have a subsystem that generates sql code for me, using some string translation mappings. The top layer is an object of the class Storage, which is the abstraction of one database.
Thus instead of working with a connection (or datasource which creates them), i have a Storage object in each of my EJB's.
Of course i don't want so many instances, because my storage is reentrant. That's why it a kind of singleton, but not really because each database (if you have multiple) would have it's own storage.