Should I use synchronized threads to control object creation?
1 posts in topic
Flat View  Flat View
Older Post First |   Reply to Topic
TOPIC ACTIONS:
 

Posted By:   Chris_Adams
Posted On:   Sunday, July 22, 2001 02:07 PM

In my design I have several sets of classes, many of which are controllers, and HAVE NO State. For example I have a class, cFileImpl that contains a method getUserFiles(). That method calls two methods on another controller class, cFileManagerImpl, who calls methods on yet another controller class, cFileSystem that actually interfaces to the data source. A main entity class, eUser, is instantiated from the start as its handle is passed downstream through these controllers so to be updated by the last object call. Each of these controller classes exist in a separately managed packages and instantiate the downstream object with new() before calling their required method. So in the case of getUserFiles() I may instantiate 6 objects, just to fill   More>>

In my design I have several sets of classes, many of which are controllers, and HAVE NO State. For example I have a class, cFileImpl that contains a method getUserFiles(). That method calls two methods on another controller class, cFileManagerImpl, who calls methods on yet another controller class, cFileSystem that actually interfaces to the data source. A main entity class, eUser, is instantiated from the start as its handle is passed downstream through these controllers so to be updated by the last object call.


Each of these controller classes exist in a separately managed packages and instantiate the downstream object with new() before calling their required method. So in the case of getUserFiles() I may instantiate 6 objects, just to fill eUser's file attributes. If 500 users login and make the same call, I could have 3000 objects performing the same thing! Ow.


Worse is there are many other controller classes that perform the same types of operations for groups, users, folders, etc. and the number of controllers are still growing. So I need to find some type of mechanism to manage all this memory as it seems the GC will be constantly busy.


What I'm considering:


1.) Object Pools - I like this idea, but it seems overwhelming to create this structure for every controller class.


2.) Turning all the controllers in Abstract classes with Static synchonized methods, but as I read more about this, I'm getting nervous about the cost of static and deadlock with synchronized.


3.) Just buying a 4GB RAM sever and let it go!!! - not the boss' perferred solution.

   <<Less
Report | Quote This | Send private message | Reply | Print

Re: Should I use synchronized threads to control object creation?

Posted By:   Alex_Chaffee  
Posted On:   Monday, July 23, 2001 12:24 PM

First, any object that contains an instance variable has state. If your object cFileImpl has any variables -- say, a pointer for the cFileManagerImpl -- then it has state.


However, if (a) there are no instance variables, or (b) all instances of cFileImpl have the same value for all instance variables, then you should consider using either a static object or a singleton object -- basically an object pool of one.


As a general rule, you don't need to synchonize methods that don't access instance variables, so your worry about the cost of static may be unfounded.


I'm not sure if what you want is a cache (same data requested multiple times) or an object pool (same object class requested for entirely different data). An object pool is only necessary if you have a high-volume server, where the Garbage Collector is noticeably slowing things down. Until you've done performance analysis, just use new and cross your fingers.


Either way, a cache or an object pool is not complicated. Refactor your code to use a factory -- replace all "new Foo()" with "foofactory.getInstance()" . Make getInstance implement "return new Foo()". Then if you need to improve performance, replace the getInstance() method with an object pool. It can be tedious but it's straightforward.

Report | Quote This | Send private message | Reply | Print
About | Sitemap | Contact