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
pgpN3icOznok4.pgp
Description: PGP signature
