we have an application (server side) using tomcat 5.5 with a db2 backend database. we want to package the application for other teams, but I'm having a difficult time figuring out how to create a way to package tomcat application and db2, so that its easy to download and install.
I read a little about cloudscape/derby and I'm wondering if that might be a good alternative to package the application. THere's probably around 3000 employees who access and use the application, but don't connect concurrently very much. the database is about 90 MB. one point I read was that cloudscape can migrate to db2 easily in case the demand gets too large. would embedding cloudscape/derby into the tomcat application be a sensible way to easily deploy to other teams?
This topic has been locked.
1 reply Latest Post - 2007-03-23T22:09:59Z by Stan
Pinned topic deploying tomcat application with cloudscape thoughts
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2007-03-23T22:09:59Z at 2007-03-23T22:09:59Z by Stan
Stan 120000HAGM267 PostsACCEPTED ANSWER
Re: deploying tomcat application with cloudscape thoughts2007-03-23T22:09:59Z in response to SystemAdminI have some slight experience with server side applications, more experience with databases (most recently Derby) but very little DB2 specific knowledge... that said, I want to offer some thoughts that I hope may be of help. For DB2 specific packaging tips you might also post your question to a DB2 forum as well..
My experience with the major DBMSs (Oracle, Sybase, etc) is that the database setup is generally done by a DBA that also takes care of software installation, upgrades, account access, security, capacity planning and all the other things that earn DBAs their keep. Applications that use such databases generally ship programs or scripts that are run by the DBA to create the database and load the data from scratch. One major reason for this is to insure the structures and data are compatable with the various architectures (e.g. ASCII / EBCDIC, etc). In the case of Derby the database files and data are platform independant so you can actually package the database with the application, unbundle it and use it directly.
It sounds like Derby should be able to handle your application needs but the only way to be positive would be to test the system - certainly 90 Mb is no problem and Derby handles concurrent access well in a server envrionment. Migrating from Derby to another standards based database should not be too difficult. One of the goals of the Derby project is strict standards compliance so migration is simplified. All databases differ at the API level and so API based objects stored in the database (Triggers and Stored Procedures) will always be an issue with migrating to a different system.
An example of deploying an application with a Derby database included can be found at: http://db.apache.org/derby/integrate/DerbyTomcat5512JPetStor.html