Mike Matrigali wrote:
There are many network, web and ejb apps that can use the embedded driver, if it is possible to localize the database access logic in the application server where the database is running.
agree
I understand . My point was that if I need to have an application utilize an application client to access DatabaseA and also have web/ejb apps access DatabaseA, I need to use the network driver as today with the current implementation of most application clients. Similar scenario is true for clustered scenarios.
Also remember that it may be better to use both the embedded driver for the part of the application that can be local to the database, while at the same time providing network driver access to parts of the application that are database client/server model. Often people don't realize that both drivers can be used at the same time. The embedded driver operations don't have to pay network transmission cost, so should perform equal or better to network driver operations (the key factor is the amount of data flowing in either direction).
I am not saying you cannot use the embedded driver, just there are some legit reasons why it does not meet everyone's needs.
A typical application that uses this model is one that can embed all application logic in an application or web server, and thus uses the embedded driver. But it wants to do network data gathering every once in awhile, so uses the network driver to do that.
Lance J. Andersen wrote:
Daniel John Debrunner wrote:
The reason that some of us always use the network JDBC driver is due to the environment we have to run in. For example, in a J2EE world, I need to be able to have my application client be able to access the same databaseSimon wrote:
Bad - One thing that concerned me greatly was the ambiguity around
whether the driver was going to be released - yes, amazing, but true -
originally the whole DB was redistributable as open source but not the
driver to access it!
To be fair the main (embedded) JDBC driver to access it was released
under open source. I was surprised how many folks immediately used the
networked JDBC driver, rather than the embedded mode. But then it was
always a mind shift for folks to understand the embedded JDBC driver was
the complete database engine. Client/Server is more naturally understood
as it is more typical.
as my web or ejb apps. This would not be possible for the majority of J2EE app servers without a redesign of at least their application client container.
The other issue is that there are a couple of problems with the embedded driver that we need to address (shreyas is working on these) that we did not encounter with the network driver.
In many cases, using the embedded driver is the way to go though.
Well, I think this has been fixed for the java
access, but as far as I know if you want ODBC you are still NOT able
to redistribute the driver. I would love to hear if this is going to
change.
Do I hear a volunteer for an open source ODBC driver for Derby?
Dan.
