> This is kind of off-topic, but I'll mentally add
>"within a servlet container", and suggest some issues
>based on that:
Yes, my code will be used within the context of a servlet
container.
>Why, exactly, do you want a singleton?
I'm trying to refactor a 5,000-line servlet into some smaller
servlets and some helper classes. Currently, all of the processing
code (code that hits the database, authenticates users, etc.) is in the
same class as the servlet. I would like to try and separate the code
that deals with the user interface from code that does the backend
processing. This way, if we want to change the user interface or allow
part of the functionality to be used by a new servlet, it should be easier
than what it is now.
The code I'm working on refactoring now allows users to sync passwords
across various systems. I've put all of the processing code in a class
with all static methods called PasswordFunctions.java. This class won't
have any class-level data members. The user-interface code for syncing
passwords has been moved to a new servlet. I believe this is the correct
way to go for this portion of the code.
We also have a database connection pool class that we'd like to use. To
allow
any servlet or helper function to access the connection pooling object, we
have
the following singleton:
public class SSOJDBCPoolHolder
{
private static LogWriter jservlog = LogWriter.getInstance();
private static JDBCConnectionPool pool = null;
private static SSOJDBCPoolHolder instance = new SSOJDBCPoolHolder();
private SSOJDBCPoolHolder() {
if (pool == null) {
try {
pool = new JDBCConnectionPool(JDBCConnectionPool.SSO,
"SSOJDBCPoolHolder");
} catch (Exception e) {
e.printStackTrace();
jservlog.log("Exception trying to create a
JDBCConnectionPool"+e);
}
}
}
public static SSOJDBCPoolHolder getInstance() {
return instance;
}
public Connection getConnection() throws SQLException {
return pool.getConnection();
}
public void returnConnection(Connection dbconn) {
pool.returnConnection(dbconn);
}
public void closeCheckedInConnections() {
pool.closeCheckedInConnections();
}
public void closeAllConnections() {
pool.closeAllConnections();
}
}
It seems like the code in the constructor could be moved
to the getInstance() method, and this class could go from
being a singleton to an all-static class. We only need one
instance of the JDBCConnectionPool.
>Or are you wanting to make sure
>there is only one instance of a thread pool?
Currently, we have singletons to allow access to our connection
pool and a singleton that allows logging to a file. We're also
thinking about adding a singleton object to act as a cache which
all servlets can reach into.
> b) Within a servlet container, you're going to
>have a hard time guaranteeing that there is really
>a single instance (of object or class). Classes
>are identified with a particular classloader, and
>different webapps use different class-loaders.
>if your webapp is distributable, you get even more
>fun. Then again, maybe that doesn't matter to you,
>see (a) above.
We're running JServ on a single server. Won't all
of our servlets get loaded by a single classloader?
Additionally, if I move the helper classes outside
of the servlets directory, they should all get loaded
by a single classloader, also, right?
Thanks for your help,
Craig Sullivan
-----Original Message-----
From: Christopher K. St. John [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 12:55 PM
To: [EMAIL PROTECTED]
Subject: Re: singleton vs all-static class
"Sullivan, Craig R." wrote:
>
> What are the advantages/disadvantages of a singleton
> class vs a class with all static methods and all static
> class members.
>
This is kind of off-topic, but I'll mentally add
"within a servlet container", and suggest some issues
based on that:
a) It's hard to discuss outside the context of a
particular problem. Why, exactly, do you want a
singleton? Eg, factory singletons sometimes need
to be replaceable, so they're objects instead of
all-static classes. Or are you wanting to make sure
there is only one instance of a thread pool?
b) Within a servlet container, you're going to
have a hard time guaranteeing that there is really
a single instance (of object or class). Classes
are identified with a particular classloader, and
different webapps use different class-loaders. And
if your webapp is distributable, you get even more
fun. Then again, maybe that doesn't matter to you,
see (a) above.
-cks
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
