I discovered this afternoon (after I got everything working - thanks to Jason's comment) that the main process in the webapp I'm building (day job) takes 15 seconds to process. It could be have something to do with the fact that the HTML page itself is 1.5MB of data (view-source, save as). And it's a very lightweight page as we're using strict XHTML and mucho CSS. So now it's time to start looking into caching frameworks. For the web/JSP side, I'll probably use OSCache. It's seems to be more tried and true, and commons-cache is still in the sandbox. If any of your have experience, chime in so I don't pick the wrong one! Another method I'm going to try is using JCS with Hibernate. Since I'm using XDoclet already, all I have to do is add the following to the top of my persistable objects.
@hibernate.jcs-cache usage="read-write"
I decided to upgrade from Struts 1.1 RC1 to a nightly build this morning, hoping to get the fix for the Validator bug that requires an Internet connection. I was also hoping to solve an issue I have where Eclipse thinks that ListUtils.sum(list1, list2) is deprecated (not so according to it's JavaDocs - Ant doesn't seem to think it's deprecated either... wierd). However, instead I was greeted with a couple of new deprecation errors that you might want to know about.
ConvertUtils.setDefaultLong(long) has been deprecated. Again, not according to its javadocs.Action.MESSAGES_KEY deprecated in favor of Globals.MESSAGES_KEY
The good news is that the Validator bug is indeed fixed and I don't have to set my proxy host/port variables for Tomcat anymore.
I'm having an interesting problem with Hibernate this morning, hopefully you can offer some assistance. Basically, I have an object called Parent that has a property called Kids. The List of Kids is set the from UI on an update using indexed properties. My UI is somewhat dynamic in that kids can be removed from the table using JavaScript - and then this record is not passed in via the request. My update works just fine, however, these deleted kids need to be removed from the database.
My initial solution was to (using Hibernate) get a list of the existing kids for the parent after the updates/inserts had occurred:
List dbKids =
ses.find("from k in class " + Kid.class
+ " where k.parentId=?", k.getParentId(), Hibernate.LONG);
if (!parent.getKids.containsAll(dbKids)) {
// loop through the dbKids and delete ones not not passed in
for (int i = 0; i < dbKids.size(); i++) {
Kid kid = (Kid) dbKids.get(i);
if (!parent.getKids().contains(kid)) {
ses.delete(kid);
}
}
}
The problem I'm having is that my kids that are passed in (parent.getKids()) contain empty Strings for their null String properties. This (I'm assuming) is done by BeanUtils.copyProperties(). However, the kids in dbKids contain null for their null properties. Any ideas/suggestions are appreciated. I'll try digging into BeanUtil.copyProperties() and see if I can solve it there.
I know I'm probably jinxing myself, but I'm going to say it anyway. I just checked my catalina.out file (a.k.a. Tomcat's log file) and I haven't had an OutOfMemory error since I upgraded to Tomcat 4.1.24. I was getting them all the time with Tomcat 4.1.18. Hopefully you've seen the same stability increase. I'm sure this site will crash with an OutOfMemory error as soon as I finish this post! ;0)
Update: I send a message to Keith to verify that Tomcat hasn't crashed since Saturday night. Here is his response.
The cron job hasn't had to restart it, and there are no out
of memory errors in the log. I can't find any sign that it
failed since then.
Keith
Sweeeeeettt!!
