db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Derby vs. PostgreSQL
Date Wed, 11 May 2005 17:20:07 GMT

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.


> 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 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.

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:
>>> Simon 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.
>> 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 database
>> 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.

View raw message