Often, databases are installed in a web server so they are able to be
shared among multiple web applications. Depending on the web server,
installation might require the server to be bounced to take effect,
although many servers can dynamically add resources. The referenced
article calls this "Casual Integration" and "Enterprise Integration".
If the Derby database is intended only for use by a specific web
application (not shared) I don't believe that the web server is even
aware of its use, and therefore no installation, configuration, or
special treatment of the database is needed. The article refers to
this as "Prototype Integration". To the web server, the application
is simply accessing files, so the only thing that's needed is to
configure the application for deployment such that file access is
permitted.
As far as I know, the only thing to watch out for is class loader
conflicts. To avoid possible conflicts among multiple applications
using Derby, the "non-delegate" property of the application should be
used. This has the effect of loading the entire Derby code base into
the application. For efficiency, if multiple applications are going
to use Derby, it might be a good idea to use "delegate" and share the
Derby code, understanding that sharing the code has more requirements
(you need to make sure that the different applications can use the
same version of Derby).
Craig
On Oct 30, 2005, at 10:06 AM, Jean T. Anderson wrote:
Legolas Woodland wrote:
Thank you for references
I read the article of embeding Derby into Tomcat
but in my case i have no full access to server to stop tomcat or
install derby into the server.
I thought Embeding means no installation requirement.
is there any way that i include some derby jar files with my web
application (into lib folder) and use it as embeded DB server ?
Check out Lance Bader's developerWorks article "Integrate
Cloudscape Version 10 or Derby with Tomcat":
http://www.ibm.com/developerworks/db2/library/techarticle/
dm-0508bader/index.html
His "prototype integration" option doesn't require touching the
Tomcat configuration. While his instructions have you stop/start
the tomcat server, I don't know if this is strictly necessary to
add derby to your existing web application. Does anyone on this
list know for sure?
-jean
Thank you.
On 10/29/05, *Jean T. Anderson* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Legolas Woodland wrote:
> Hi
> Thank you for reading my post
> I should design and implement an application which is going to
run on
> tomcat 5.5 and Database can be one of derby ,sqlServer ,
Mysql.
> Problem is that this application should be able to have
about 15
> -20Transaction in 1 second .They have no extra power servers ,
just an
> ordinary hosting plan.
> my question is : which of this database is better to choose ?
> i thought that derby could be better because it can be embeded
into my
> application .
> can derby carry out 15-20 transacion in 1 secod ?is it
feasible with
> using DAO pattern and plain JDBC ,or it need some other
requirement ?
> I have Struts and mysql experience I learned derby but i
did not
use it
> yet.
> before they ask me about implementing this project they used
PHP+Mysql
> and it seems that that application Hangs on +10 hits per
second
> each hit had some Insert one update and 2 select at least.
>
Dan Debrunner's "Introducing Apache Derby" presentation from
ApacheCon
US last November might have some helpful info for you. You can
download
it from http://db.apache.org/derby/binaries/djd_derby_intro.pdf .
A "Guidelines" section starts on slide 19. Slide 24 lists 100-500
updates per second -- but, of course, your actual performance
will
depend on the complexity of your transactions.
Also you might be interested in an article Stan Bradbury
contributed
yesterday that shows a way to embed Derby in Tomcat 5.5. You
can find it
here:
http://db.apache.org/derby/integrate/
DerbyTomcat5512JPetStor.html
<http://db.apache.org/derby/integrate/
DerbyTomcat5512JPetStor.html>
I hope this helps.
regards,
-jean