sunish kumar wrote:
Hi,
Sorry to ask a simple question.
Is it okay to use derby as embedded database in my web application?
In such case where the database files reside? What I am planning is to
make an application which will just start working with database
features with out any extra set up. Just copying the war file to
webapps directory should do everything. It means there may be similar
applications in the same application server which uses its own
embedded database. How it will affect the system performance.
Thank you,
Sunish
Hi -
I've seen many people have problems trying to implement the architecture
you describe. It is also an inefficient use of resources (multiple
caches, transaction managers, etc.). The main problem stems from each
WebApp having it's own Classloader environment that is low in the Server
hierarchy. This is good in many standalone situations but with a
shared, multi-user resource like Derby such isolation presents a
problem. The rule of thumb is that only one instance of the Derby
driver should be loaded in a single JVM and Derby should always be
loaded at or near the top of a Classloader hierarchy. The problem, as I
understand it, is with the shared in-memory structures/caches that get
created and that Derby sets up it's own Classloader hierarchy. When
multiple instances of the Derby engine are loaded across different
Classloaders in a single JVM the system will not function reliably.
Derby should be thought of a JVM wide resource to be shared by all
applications running in the same JVM.
