Thursday, March 27, 2008

Phobos, DB Pooling And Connections

For those who have followed my data examples in the past, and have tried
them out, here is a recent issue I ran across. I have designed what
some would call a data facad, crud module, business object. Whatever,
you want to call it, it handles all of the data access for a particular
table. I was testing this on my laptop from the Netbeans environment,
and every time a page was requested five times, the Phobos runtime would
go into an endless loop. However, when you stopped the run time, a null
pointer exception would be thrown on this line of code:

conn =
java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");

What this line does, is in my previous data examples. After doing some
checking around on Google about Java data pooling, it finally dawned on
me that I was running out of connections. I was closing the
connections, but the code was not getting executed. Here is an example
of the offending code in the module method which is called.

return obj;
stmt.close();
rset.close();
conn.close();

The code is never run, because execution stops at the return statement.
Some might think this would be obvious, but this behavior is not the
same in an ejs file or controller. My assumption was that it would get
run, and so we should get the data back asap. We could the worry about
cleanup code. However, all cleanup code needs to be run before the
return statement. It should look like this.

stmt.close();
rset.close();
conn.close();
return obj;

Small change, but big results. If we abstract our data access into
modules, it is fast and easy to clean this up versus having it scattered
in scripts.
Below is an example of a method of the crud class. I will hopefully be
posting all of the code for the data layer soon.

Happy Coding!

var stmt = null;
var rset = null;
var strSql = null;
// oConn is the connection pool set in application startup
conn =
java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");
strSql = 'SELECT * FROM article WHERE ARTICLE_PK = ?';
stmt = conn.prepareStatement(strSql);
stmt.setInt(1, articleId); // articleId is passed in
rset = stmt.executeQuery();
// Call method used to generate a json object of record set
obj = this.generateJson(rset);
obj.status = true;
stmt.close();
rset.close();
conn.close(); //clean up
return obj;

Saturday, March 15, 2008

Sun Webserver on Debian

Recently I needed to put together a web server for a few websites. The
hardware was put together on the cheap. It is amazing what you can get
with a few hundred dollars. The hardware consisted of a MSI motherboard
with an AMD dual core processor, two gig of ram and two sata hard
drives. All the hardware came in under $450.00. I installed the latest
version of the AMD64 Debian to run a headless system with software raid
1. I then installed Sun's web server which is available for free
without support. It also comes with 64 bit support for the AMD
processor. The only wrinkle I ran into during the install was that the
JDK that comes with the installation of the web server will not install
on Debian because of missing libraries. I worked around this by
installing the latest JDK from the Debian repository. I am using the
stable version so I did use apt pinning to pull that from the unstable
branch as some libraries are needed that are not in the stable branch.
I also installed Postgres 8.3 this way. Other than that, the install of
the web server went flawless. The start and stop scripts even appeared
to start the web server on system boot which was very nice, especially
since Debian is not officially supported by Sun.

After the install, web server maintenance was a breeze. I needed to
setup a few virtual hosts and I wanted them to be ip based. It took all
of about three minutes through the web interface. I looked at the Sun
web server a few years back and found the web interface to be somewhat
confusing. However, they have since redone the whole interface and it
is much more intuitive and straight forward. I found it very easy to
work with.

The web server also supports webdav out of the box. I decided to try
to allow users to change their files using webdav instead of setting up
an ftp server. This would trim one running process and also be one less
security detail to lock down. The webdav was easy enough to set up, but
I did have a slight problem getting the security to work properly.
However, a short trip to the Sun web server forum, where I received
several helpful answers almost immediately, solved the issue.

I chose to try Sun's web server over Apache because not being a long
time Linux guru, and needing extremely tight security on web systems in
todays environment, I felt much more comfortable with Sun's server.
With Apache, set up can be quite complicated and, in my opinion, it is
much easier to accidentally open up a security hole. It is too bad
Sun's marketing material bills the web server as best used for medium to
large installations, because it will work just as well for a small company.

One other thing I wanted to mention was what I was very impressed with
the speed of the server. It is fast at serving content up. I do not
claim to have benchmarks and what not, but coming from 32 bit hardware
and operating systems running IIS and SQL server, I was impressed. I am
sure it was a combination of the Linux kernel optimized for the
processor and then the web server optimized for the 64 bit chip, but the
speed is impressive nonetheless.

On a different note, when time permits, I will be trying out running a
Phobos app on Sun's web server. The web server is convenient over the
application server in the fact that it binds to port 80 and runs out of
the box as user nobody and has lots of virtual hosting tools. You can
use Glassfish to do the same thing, but of course it is not geared as
much for that purpose. Phobos could take the place of say asp or php on
a web server for a web host. A company could advertise web hosting
with server side javascript enabled out of the box with an open source
database.

I am happy to see Sun accepting the model they have for software as far
as licensing and support. Even though small companies may never want to
pay what a Sun support contract would cost them, I have found the Sun
employees on the forums to be most helpful. The more system admins and
developers that can use the software, the bigger ecosystem of free
support will be available out there on the web free of charge for small
users. With software, the better products doesn't always necessarily
win, it is the product that develops the largest user base for one
reason or another. Profits understandably must made, but is uncanny how
sometimes that profit will kill the product in the long run because
another product become more popular. I believe Sun is heading in the
right direction as far as growing their user base for their products and
I am happy to see it. Now if we could only get Solaris to run on dirt
cheap hardware . . .