I have the following question: What should happen if a caller of a singletone attempts to instanciate it with different file name?
Example:
1. Data.getInstance("c:\db.db");
2. Data.getInstance("d:\db.db");
Should I ignore it?
code:
--------------------------------------------------------------------------------
// For lazy initialization public static synchronized Data getInstance(String fileName) { if (instance==null) { instance = new Data(fileName); } return instance; }
--------------------------------------------------------------------------------
I did have Data class mutition, not a singletone. (My all remote connection factory creates a Data instance once and put the instance in a C-tor of RemoteObject every time).
Since I do synhronize all methods on "this", I am afraid that Sun's automatic test can attemp to create may istances of Data. My locking and synchronization will not work of course.
SCJD 1.4
why not create a singleton LockManager for all Data instances and synchronize on it?
Phil:
I'll dare now what I never dared before : asking you - with a red face - what C-tor means ...
Constructor
For me, those getInstance() calls are typically multiton. Where do you see any singleton ?
??? What is method for instanciating is used then typically for a singletone ???
I use a multiton design, but its names implies, instances are multiple (I store Data instances in a WeakHashMap)...
I hope it is not WeakHashMap where you implicetely manage your locks?
2) Shame on me. My understanding of multiton was totally wrong (see my previous mail).
Your sample for the multition looks great. It seems to me honestly saying the ONLY solution (As I said I can't imagine how a singletone can be applied to our assignement).
Just to make sure: dataInstances is a static class variable in Data class:
code:
--------------------------------------------------------------------------------
public class Data{static Map dataInstances = new WeakHashMap();... public static Data getInstance(String dbFileName) { }}
--------------------------------------------------------------------------------
Is it right?
Sorry for all these stupid question, I am currently in two projects and I am totally tired
Tx,
Vlad
P.S. Phil, I owe you something: It seems that you prevented me from a very very big mistake!
But be aware that your "synchronized" keyword in getInstance() (synchronize at the class level) has nothing to do (no relationship) with the "synchronized" keyword you use in your read() method (synchronize at the instance level)
Forget the trim() on fileName, it's useless IMO
Such a way of coding really hurts me
The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded. Note that a value object may refer indirectly to its key via the WeakHashMap itself; that is, a value object may strongly refer to some other key object whose associated value object, in turn, strongly refers to the key of the first value object. One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get.
Have you tested it?
Do you know how should I handle it?
But as the key in my implemtation is the filename (which is probably a local variable), you get rid off ... immediately !
This class is intended primarily for use with key objects whose equals methods test for object identity using the == operator. Once such a key is discarded it can never be recreated, so it is impossible to do a lookup of that key in a WeakHashMap at some later time and be surprised that its entry has been removed. This class will work perfectly well with key objects whose equals methods are not based upon object identity, such as String instances.
and in the same time so ashamed to have suggested to you a bug instead of a solution
Ok, here is the final and tested version:
It is a very elegant solution, but I am just a bit concerned if it is not too overcomplicated.
I guess that Jim has also multition. I know also that Andrew was considering a singletone.
Guys please, could you comment our discussion with Phil?
The problem with a multiton (getInstance(some_parameter)), is that you offer the world a way to instantiate new objects (if they don't exist yet), without giving any way to drop them. Storing the instances in a WeakHashMap is just the way I found to get rid of that "disinstantiating" issue. It's just my way of doing and I never discussed it with others. (Andrew, Jim, others, do you agree with it ?).
I am still wondering how could others use singletone for Data.
"I'm not back." - Bill Harding, Twister
Well, or if I'd tested it carefully; but I'm not sure I woud have thought to check carefully for GC of unused multitons, given that the class is really only used as a singleton under the GUI I've provided.
Anyway, I used a WeakHashMap with File objects as keys, and WeakReferences as values, as suggested in the WeakHashMap API. My factory method looks like:
Looking at Vlad's code - ummm, why use a Map at all if you're just going to iterate through everything? Seems like you're using the Map backwards.
In fact, I do guess you'll get in trouble there. But if it's the case, please don't change your main db design choice : keep it single-table (it's very defendable), forget the multiton and replace it by a singleton.
"I'm not back." - Bill Harding, Twister
[Vlad]: // SHOULD I DO IT???
I would, yes.
1) Singletone throwing an exception if file name is not equal to the the one from existing instance of Data (if an instance already exists).
2) Multiton. It is very elegant a beatuful solution. You insist that this approach makes only sense if multitable design for db is applied.
I don't really agree with this statement. I have a single table approach. But, having a multiton allows me:
- correctly handle situation where different filenames are used by Data.getInstance()
- It allows me to have a remote server serving two different databases (not tables).
E.g. I han have RemoteConnectionFactory with two createMethods:
DBRemote Factory.createDB1(); // database 1 (file "db1.db")
DBRemote Factory.createDB2(); // database 2 (file "db2.db")
1) or you still beleive that in single table design multiton not needed?
2) Phil, It seems that Jim confirmed my that my version of singletone (thwoing IllegalArgumentEx) is Ok, but I still didn't understand your point regarding how would you implement a Singletone with getInstance(String s)?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
I did have it as a multiton based on the database file name, however I had not gone so far as to put it in a WeakHashMap.
Back when I was considering having a LockManager for my submission, I did have it as a multiton based on the database file name, however I had not gone so far as to put it in a WeakHashMap.
Jim:
Though if you use WeakReferences for the values, the problem should go away. That is, the Map may still contain old keys and WeakReference objects which you don't need anymore, which aren't being GC'ed correctly, but those are probably small compared to your Data object. Well, they're definitely much smaller than my Data, since I use full caching. So for me, using WeakReferences is the key, and using WeakHashMap in addition to that just provides a little extra memory that can be freed up. If you want to have no caching, and plan for [i]lots of tables that take up very little memory, then perhaps the memory used by the keys and references is also significant, and the WeakHashMap is important.
"I'm not back." - Bill Harding, Twister
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
You talk here about LockManager. I ment Data class (I don't have any lockManagers as you know).
Did you allow multiple Data classes (I don't beileve it), did you make you Data class as Singleton or Multiton.
If the answer is Multiton:
Do you mean that you just used a standard collection (Map or some else) without taking any other care?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
you should not rely on a file name but rather use a File object
And how can they instantiate it in this case?
Although I do not agree that someone must manually specify a constuctor
I cannot understand why your variable called �lockManager� is declared as static.
It means you have one instance of Lock Manager per JVM (per your application). Because your design allows to work with many tables you are forced to keep control over �record number � table name� pairs.
Could you please answer the following questions?
- Is my data /locking approach correct?
- If your answer is �no� please justify it.
- If your answer is �yes� why have you chosen such a complex approach.
I would like to ask you one more time.
Could you please write an algorithm of your recursive method? It sounds really interesting to me.
Please do not shoot the fish in this barrel. But you can shoot at this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|