db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: BLOB : java.lang.OutOfMemoryError
Date Wed, 31 Aug 2005 17:28:16 GMT
Ah, you have struck upon a nerve, the knee kicks up.  If I were skilled 
at finding old threads in our mailing list (which I'm not) I would show 
you the discussion we'd be having on derby-dev about code sharing.

I will try to summarize, but I'm sure others will chime in:

    * Currently the network client and the embedded driver and the
      network server are all totally independent packages of code
      (except for some shared constants)
    * We have had numerous discussions about enabling more code sharing,
      but it's trickier than you might think
    * I think we are coalescing on making it a goal to incrementally
      share more and more code. Two major areas: sharing the network
      code between the embedded client and the network server, and
      sharing the driver code between the embedded and network drivers. 
      Other areas include utility services that span these areas.
    * Your participation in this effort would be most appreciated.  So
      far we haven't made much progress mostly because of lack of
      resources (and also a lot of back and forth debate about exactly
      how to do it).

Thanks,

David

Michael J. Segel wrote:

>On Wednesday 31 August 2005 10:49, Satheesh Bandaram wrote:
>  
>
>> Thanks for the offer.. It would really be great to have more developpers
>>working on Derby. Join the derby-dev alias to participate in the
>>development.
>>
>> Derby embedded driver already has the capability to stream blob/clob,
>>without requiring reading them completely into memory. It would be great to
>>enhance Derby network server and Derby client to support this kind of
>>behavior.
>>
>> Satheesh
>>
>>    
>>
>[SNIP]
>
>This may be a dumb question...
>
>Maybe its hindsight, but why isn't the Server Framework either a subclass or 
>an extension to the embedded driver? Someone had posted that the Network 
>Driver utilized the embedded driver... (Or is that bathtub gin affecting my 
>memory?)
>
>I guess it goes more to the point of why not have more focus on a "universal" 
>driver?
>
>
>  
>

Mime
View raw message