db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Network Server and client concerns
Date Sun, 19 Feb 2006 07:51:47 GMT
In an earlier thread today, I mentioned that we had bigger issues with
Network Client/Server than a limit of 64K statements in a batch.  Bryan
asked what those were.  Here is my first shot at a high level view of
some of the big issues as I see think surrounding quality and wide
spread adoption of our network offering.

1) Security issues
- Cannot send encrypted user/password with  non-IBM jvm (DERBY-65).   
DERBY-528 would help.
- Setting up the policy file is not very intuitive and documentation is
lacking (DERBY-474).  I fear often folks go with the -h with no
policy file, allowing huge security breaches. 
-  There is no data stream encryption.
-  We  need a comprehensive look at security. I'd like to see network
server start up secure and remotely accessible by default

2) Memory Issues
- There are serious outstanding memory issues with network server. 
DERBY-326 (hopefully for 10.2), DERBY-550
 DERBY-206.  Also we discussed better buffer management in network
server. I don't know if there is a Jira for this.
- Memory profiling would be worthwhile to uncover more.

3) Exception Handling issues
  I think that there needs to be a comprehensive look at the  Network
Server exception handling.  DERBY-1011, DERBY-159

 4) Adoptability and compatibility
- There is a significant disconnect in  behaviour between embedded and
client, which will become more difficult to correct as application come
to depend on one or the other.   We have documented that we plan to
match embedded where possible, but practically speaking it would be best
to get these done sooner rather than later.
DERBY-310 and linked issues

5) Portability  issues
   - There are currently a lot of encoding bugs.  Traditionally  Network
server has proved to be less portable than embedded.    

6) Testing
    We need to expand Network Server and client testing.  DERBY-209. In
general client/server is not as solid or as well   tested as embedded.
Converting tests will uncover more bugs.   Also I worry that the code is
regression prone because of lack of testing.
    We need to improve code coverage, especially in the am package of client
    We need some sort of regular or automated Servlet testing. 
    We need client/server backward compatibility testing. (DERBY-516) +
derbynetclientmats runs with different client/server combinations.

7) Buggy  and intuitively worrisome areas
  - Client XA
  - Client DataSources
  - Large Objects
  -  Database and result set metadata
  - Keeping connection/statement  state in sync with client/server for
autocommit, holdabilty, isolation level etc.
  - I have vague concerns about locking due to all the prefetching.  
More testing in this area is definitely warranted.
  - Client has a lot of  code that I think can be streamlined and
probably has latent bugs and performance impact.
     Examples: The commitAndRollback listeners code,  encoding handling
and converters.

O.K.  That's it for now. There was going to be 8) Robustness and
Performance but I will save that for another day.


View raw message