db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2451) a client can crash connections of another client
Date Thu, 05 Jul 2007 12:48:36 GMT
Hi,

>>>>>>>>>>>> quartz (JIRA) wrote (2007-07-04 08:22:04):
> quartz commented on DERBY-2451:
> -------------------------------
> 
> DERBY-2264 doesn't solves that problem. I think some misleading
> comments have been made.
> 
> You have to understand that with a "client" connection, one can
> crash another process client connection.  It has nothing to do with
> privileges of the database owner.
> 
> The database "stats" owned by "bob" was started with a standalone
> server process.  If a remote process connects through a client
> connection with "bob" credentials to the server, it is still NOT
> allowed to shut this stats database down.

If I understand you right, you have two clients using the same
database and when one of the client shuts the database down, you get
some error in the other client because the shutdown succeeds.

> 
> The remote process isn't the controller of this database just
> because it used the owner credentials.  There is a big difference
> between disconnecting and performing an administrative shutdown (
> which should require administrative credentials and privileges, not
> only ownership privileges).

Well, this is the way Derby is designed (if my understanding of the
problem is correct), and you may like or dislike it and we may discuss
if it is a good design or not. With DERBY-2451 (from version 10.3) you
have the option of using another user in the clients than the database
owner.

You may also check if it's possible to change the client's behaviour
in this respect.

In the general case, it is not possible to stop on client from doing
changes that will produce an error in another client (E.g. client A
may drop a table which client B needs and when client B tries to
access that table, an SQLException is thrown and if client B was not
written to handle that case, it may crash).

> On the matter of developing a fix: there are people far more
> efficient than me that should fix this critical issue.  And there
> are responsible people out there, making decision, otherwise
> everyone could check in, mess up and leave.  Meanwhile, Sun's javadb
> depends on apache derby. So I don't know what incentive you need
> other than a huge user base waiting...

Everybody may *contribute* code, but only Derby committers may *check
in* code. If you contribute, one or more Derby developers will
look at your contribution and comment on it and when the quality is
ensured, it may be checked in by a Derby committer. 

Bernt

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

Mime
View raw message