Re: making Derby secure by default
I strongly recommend that this topic be posted to derby-user for comment. Afterall it is their applications that will be impacted should the secure by default be implemented. For my part I agree with Kathey, leave the default as the old behavior (especially for embedded) and strongly recommend that groups that do not already secure derby at the application level set SECURITY = ON (or whatever the flag may be). My experience is that Derby is not broken in this regard so it need not be fixed. However, making it very easy to turn on all the security features is an excellent ease of use enhancement and I support this. Had this thread been taken to derby-user you I would have responded earlier. Regarding Derby embedded. The 100+ product release teams I work with that bundle embedded Derby do so because of it's ease of use. The embedded Derby system is protected by the application level security that protects the larger system. The teams see elegance in this simplicity, it sets Derby apart from most other systems. Many teams have used Derby since version 10.3 and greatly appreciate the simplicity of moving from one version to another. It won't be the end of the world should these teams have to add an additional property to maintain original behavior but some will ask why the old behavior was not the default. Without taking this to the derby-user group can the development community say they did due diligence in making this decision? --- From: Kathey Marsden kmarsdende...@sbcglobal.net To: derby-dev@db.apache.org Date: Tue, 13 Sep 2011 15:29:30 -0700 Subject: Re: making Derby secure by default On 9/13/2011 10:57 AM, Rick Hillegas wrote: 2c) To ease the migration to 11.0, it might be possible to add a single knob which lets an application opt-out of the 11.0 defaults and instead run with the 10.x security defaults. I think a single knob is a good idea but the default should be off to preserve backward compatibility and the zero admin aspects of the product at this time. Warnings and education can be used to coax users to transition and then maybe after multiple releases with the knob the default could be changed and the major version changed if there is enough experience with the super knob to understand all the steps that have to be taken in addition to turning it on. Concerning topic (1), it seems to me that the biggest hurdle to building a secure-by-default Derby is our lack of user management. The BUILTIN security mechanism has many defects which make it unsuitable for use in production. Here is my short list of security features which I think that we should build: o DERBY-866: Derby User Management Enhancements o DERBY-2133: Detect tampering of installed jar files in an encrypted database o DERBY-2206/DERBY-2250/DERBY-22 53/DERBY-2252: Provide complete security model for Java routines o DERBY-2363: Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings. o DERBY-2436: SYSCS_IMPORT_TABLE can be used to read derby files o DERBY-2470: No authentication required to restore a backup o DERBY-: User name corresponding to authentication identifier PUBLIC must be rejected o DERBY-3495/DERBY-3476/DERBY-2109: Enable System Privileges checks o DERBY-4354: Make it possible to grant java permissions to user jar files that are stored in the database o DERBY-5400: Toggling of network tracing should be protected by requiring the user to specify the credentials of the system administrator. o DERBY-5401: The NetServlet should require system administrator credentials in order to perform its operations on a server which requires authentication. I would appreciate your thoughts about this proposal. Thanks, -Rick
[Proposal for Review] The fix for DERBY-3347 is important enough for the Development Community to issue a recommendation the User Community to upgrade.
Hello Developers - I would like to follow up on the suggestion made by Kathey Marsden that an announcement be posted to derby-user recommending that version 10.3 users upgrade to a Derby version that contains the fix for DERBY-3347. The email from Binoy Thomas this morning could be an incident of DERBY-3347 [Subject: DB gets corrupts in 10.3.1.2!!] In hopes of moving this forward I have drafted such an announcement and would greatly appreciate review and suggestions from the developers most familiar with this bug. In the message below I have listed the reported error and loosely described other errors that might be generated should a database become corrupted by this defect. I recommend a course of action and use of database consistency checks. If particularly Knut would review and comment on the bug related information I would be very grateful. Word-smithing and other adjustments are also welcome. If this proposal concerns you please respond or I will assume a lazy consensus. And a couple of ideas to give this proposal more weight: Would a PMC member volunteer to sponsor this post? Having an acknowledged leader of the development community would give the recommendation more weight in many circles. Can the recommendation, if posted, be identified as being made by or at least supported by the Development Community or a majority of the Development Community? Again this would give more weight and bring more attention to the recommendation. As currently worded the recommendation has no author other than the sender of the message. *** For Review and comment *** NOTICE TO ALL DERBY v10.3 USERS : CRITICAL FIX NOW AVAILABLE The Bottom Line: It is strongly recommended that you upgrade to Derby 10.4.1.3 to avoid any chance of database corruption due to DERBY-3347. Alternatively you can build version 10.3 from the current codeline which also contains the fix for this defect. This bug can cause unrecoverable database corruption during periods of heavy, multi-thread I/O operations. The error produced in the test case used to diagnose the problem was: ERROR XSDB3: Container information cannot change once written: was 0, now 80 It is felt that other errors might also be generated when this type of corruption occurs. The corruption message will most likely refer to page 0 of the container. EXAMPLE: ERROR XSDG1: Page Page(1039,Container(0, 5856)) could not be written... This bug corrupts the pages on disk and can go unnoticed. If you do not run database consistency checks regularly it is recommended you begin doing so as soon as possible after the upgrade. To insure that corruption has not already occurred in existing databases, after upgrade run the database consistency at least once to validate all tables in the database. This process is documented at: http://wiki.apache.org/db-derby/DatabaseConsistencyCheck If corruption has already occurred the database will need to be recovered from the last good backup. Version 10.4.1.3 can be downloaded from: *** END of Proposed Post ***
Re: [jira] Created: (DERBY-3620) Problem with Derby on Windows 2008
fyi - The machine is IPv6 and Eric will be redoing the test with the recommneded JVM settings for dual stack machines. Eric Kirchstein (JIRA) wrote: Problem with Derby on Windows 2008 -- Key: DERBY-3620 URL: https://issues.apache.org/jira/browse/DERBY-3620 Project: Derby Issue Type: Bug Components: Network Client, Network Server Affects Versions: 10.3.2.1, 10.1.3.1 Environment: OS: Windows 2008 Server (32- and 64-bit) Java version output on 32-bit machine: java version 1.4.2_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) Java version on 64-bit machine: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20070725 (SR5a)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows Vista x86-32 j9vmwi3223-20070426 (JIT enabled) J9VM - 20070420_12448_lHdSMR JIT - 20070419_1806_r8 GC - 200704_19) JCL - 20070725 Reporter: Eric Kirchstein Priority: Critical Our component, IBM Autonomic Computing Deployment Engine, has a PMR against it relating to a hung install on Windows 2008 platforms. I have narrowed down the hang to a call we make to the NetworkServerControl class. From the command line on both 32- and 64-bit systems, I run the following: java org.apache.derby.drda.NetworkServerControl sysinfo -p 4130 This is just an example command, but suffice it to say that this hangs indefinitely on both systems, with any port specified, open or closed. This has been opened as a severity 1 critical issue on our component, due to the fact that it is blocking test on one of our deployers. Each 24 hour period that this is not resolved results in a full day lost for their test team, so time is of the essence. Here is the output of java org.apache.derby.tools.sysinfo on the 32-bit system: -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: C:\ekirchst\derbynet.jar OS name: Windows NT (unknown) OS architecture: x86 OS version: 6.0 Java user name: Administrator Java user home: C:\Users\Administrator Java user dir: C:\ekirchst java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\ekirchst\derby.jar] 10.3.2.1 - (599110) [C:\ekirchst\derbynet.jar] 10.3.2.1 - (599110) -- - Locale Information - -- And here is the output of the same command on the 64-bit system: -- Java Information -- Java Version:1.5.0 Java Vendor: IBM Corporation Java home: C:\Program Files (x86)\IBM\Common\acsi\jre Java classpath: C:\ekirchst\derbynet.jar OS name: Windows Vista OS architecture: x86 OS version: 6.0 build 6001 Service Pack 1 Java user name: Administrator Java user home: C:\Users\Administrator Java user dir: C:\ekirchst java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\ekirchst\derbynet.jar] 10.1.3.1 - (417617) -- - Locale Information - -- I'd be happy to answer any further questions to help resolve this issue quickly. Thank you in advance for your help!
Re: Derby crash (urgent)
-- top posting -- Hi Bassel - It would help to have the information from SYSINFO (version, platform and JVM). Are you able to recover from this or is the database lost? It sounds like you understand what is going on - database pages are either 1) not being written to disk properly - OR - 2) are being corrupted / deleted once they are written to disk Hence the files on disk are not in sync as evidenced by the checksums are not matching what is expected. The JVM, OS and underlying hardware handle the writes so I would start by looking at your JVM, your I/O and storage systems. Check the logs for errors, etc. I am aware of an intermittent 'Invalid Checksum' failure that stopped happening after upgrading from an initial release of a JVM to the current release/update of the JVM. If possible, test with an alternate JVM to see if the problem happens when using JVMs from multiple vendors. Once these possibilities are eliminated look at the application and runtime environment. Could you be double booting the database? In most cases Derby prevents double booting but on some OSs and older JVMs it could still be a problem. It is possible to double boot Derby within a single JVM by loading the Derby driver TWICE in different classloaders. If you are using multiple classloaders be sure to check for this. Lastly be sure you are using regular (not-buffered) I/O to a disk that is physically connected to the machine. I/O to network mounted disks is not reliable. This is all I can think of at the moment. Good luck with chasing this down. Please post what you find so others can benefit from your findings. Bassel Kh wrote: Hi, We have a critical issue with derby (version: *10.3.2*) which we use in embedded mode in our application. Several times (not to say most of the times), a restart of the application, especially when some transactions are going on, the database gets corrupted (invalid checksum exception). After reading many posts about eventual problems in derby, we found problems that look like ours (for instance: http://www.mail-archive.com/derby-dev@db.apache.org/msg46177.html), but no clear-cut that the problem has been solved. It is to be noted that we do a graceful shutdown when closing the application and the logs show successful executions. It also looks like only some tables in the database have the problem since some modules keep running correctly, but there are no conditions or symptoms prior to the error, it happens at random (we carried on several tests with different modules on different databases). Do you have any solution or suggestions to this problem? We have a customer release going on and we would appreciate if you could reply as soon as possible. Please find below the exception we are getting: Caused by: java.sql.SQLException: Invalid checksum on Page Page(0,Container(0, 1568)), expected=2,264,079,051, on-disk version=6,651,942,472,428,708,205, page dump follows: Hex dump: : 0076 0001 0002 .v.. 0010: 0006 0020: 0001 0030: 0040: 0050: 0060: 5000 P... 0070: 0080: 0090: 00a0: 00b0: 00c0: 0010 2a73 7973 .sys 00d0: 2d70 6163 6b61 6765 2d6d 6772 2a3a 2070 .package.mgr...p 00e0: 726f 6365 7373 696e 6720 6e65 7720 6a61 rocessing.new.ja 00f0: 722c 2027 433a 5c50 726f 6772 616d 2046 r...C..Program.F 0100: 696c 6573 5c53 7068 6572 6520 4e65 7477 iles.Sphere.Netw 0110: 6f72 6b73 5c41 7265 6e61 2050 6c61 7466 orks.Arena.Platf 0120: 6f72 6d5c 706c 7567 696e 735c 6165 2e73 orm.plugins.ae.s 0130: 7068 6572 652e 6172 656e 612e 6e65 7477 phere.arena.netw 0140: 6f72 6b4d 616e 6167 6572 2e63 6f6d 6d6f orkManager.commo 0150: 6e5f 322e 322e 315c 636f 6d6d 6f6e 2e6a n.2.2.1.common.j 0160: 6172 270d 0a2a 7379 732d 7061 636b 6167 arsys.packag 0170: 652d 6d67 722a 3a20 7072 6f63 6573 7369 e.mgr...processi 0180: 6e67 206e 6577 206a 6172 2c20 2743 3a5c ng.new.jar...C.. 0190: 5072 6f67 7261 6d20 4669 6c65 735c 5370 Program.Files.Sp 01a0: 6865 7265 204e 6574 776f 726b 735c 4172 here.Networks.Ar 01b0: 656e 6120 506c 6174 666f 726d 5c70 6c75 ena.Platform.plu 01c0: 6769 6e73 5c61 652e 7370 6865 7265 2e61 gins.ae.sphere.a 01d0: 7265
Re: Installing a SecurityManager by default when the server boots
I obtained a positive reaction from a group with a large install base that will be transitioning to version 10.3. Derby and Network Server are used with sample code and readily available for use as a business system data store. The statement I received is: I am all for it. Anything that will mean not breaking customers out of the box is a good thing. Rick Hillegas wrote: As of release 10.3, when you boot the network server from the command line, the server installs a Java SecurityManager with a default policy. This change (DERBY-2196) limits the ability of hackers, connecting from arbitrary machines, to use Derby to corrupt the environment in which it is running. In addition, this change provides a foundation on which we can add more security features incrementally. As a result of this change, we have learned more about how Derby behaves when run under a SecurityManager--that in turn, has helped us discover more permissions which we need to add to the template used as a starting point for configuring a Derby security policy. Unfortunately, this change has proved painful to some users. See, for instance, DERBY-3086 and the ongoing discussion on DERBY-3083. Now that we have some experience with the 10.3 release, I would like to ask the community to review the wisdom of this change. Do we still think that this is the correct default behavior? Or should we consider turning off this feature in the upcoming 10.3 maintenance release? Thanks, -Rick
Re: Installing a SecurityManager by default when the server boots
To clarify the statement I received and passed onto the community. The 'positive reaction' was to the OR case: ...Or should we consider turning off this feature in the upcoming 10.3 maintenance release? With the current behavior (starting the security manager by default), this group is looking at having their upgrade installer add the -noSecurityManager flag to the NS startup scripts for their existing installations. In addition they are discussing issuing a caution about this behavior in their release notes in case a customer has created their own startup script and do not specify a security manager. Stanley Bradbury wrote: I obtained a positive reaction from a group with a large install base that will be transitioning to version 10.3. Derby and Network Server are used with sample code and readily available for use as a business system data store. The statement I received is: I am all for it. Anything that will mean not breaking customers out of the box is a good thing. Rick Hillegas wrote: As of release 10.3, when you boot the network server from the command line, the server installs a Java SecurityManager with a default policy. This change (DERBY-2196) limits the ability of hackers, connecting from arbitrary machines, to use Derby to corrupt the environment in which it is running. In addition, this change provides a foundation on which we can add more security features incrementally. As a result of this change, we have learned more about how Derby behaves when run under a SecurityManager--that in turn, has helped us discover more permissions which we need to add to the template used as a starting point for configuring a Derby security policy. Unfortunately, this change has proved painful to some users. See, for instance, DERBY-3086 and the ongoing discussion on DERBY-3083. Now that we have some experience with the 10.3 release, I would like to ask the community to review the wisdom of this change. Do we still think that this is the correct default behavior? Or should we consider turning off this feature in the upcoming 10.3 maintenance release? Thanks, -Rick
Re: Confustion about locale and error messages
The confusing paragraph is old information and lists the old URL attribute: /locale=ll_CC/ rather than the new URL attribute /territory=ll_CC./ This should be corrected and some the behavior it tries to convey may not have made it into Derby?? The tools guide seems to have a good explanation, however. The confusing paragraph also appears to me to be performing a mash-up of two different topics - database locale and Tool locale. The two should be discussed in separate sections. Someone who has delved into the code could probably clarify further but that is not me. All I can provide is demonstrations - it will take a better witter than I to describe this verbally. Some important background for what follows: 1) There is the database locale (aka territory=ll_CC) that determines (but only a database create time) what supported message library (e.g. derbyLocale_de_DE.jar ) is loaded into the database. These are the messages associated with the SQLExceptions presented by the Derby engine and can be displayed using: SELECT * FROM SYSCS_DIAG.ERROR_MESSAGES These stay with the database regardless of System JVM locale setting. If not specified the System JVM setting is used. 2) The tool session locale (The JVM system locale): This is application dependant and will almost always be the System JVM default locale - it changes some messages that IJ presents to localized versions like the welcome/IJ version string, the 'row selected' message, the tag ERROR seems to get truncated but the message indicating where a syntax error is found seems to always be in English (at least on my machine). and for IJ, with localizeddisplay on the JVM/tools session local determines the localized display format for numbers, dates, times, and timestamps. It does not change the IJ generated error messages as far as I can tell. Based on my experimenting with databases created with different territories here is what appears to happen. NOTE: my default System locale is en_US java org.apache.derby.tools.ij ij connect 'adf:adf:aer'; ERROR 08001: No suitable driver - english message for application level / IJ error 08001 ij connect 'jdbc:derby:mxdb;create=true;territory=es_MX'; -create a Spanish MX database ij select * from fred; ERROR 42X05: La tabla/vista 'FRED' no existe.- get Spanish MX error messages for Derby errors ij connect 'jdbc:derby:deDEdb;create=true;territory=de_DE'; -create a German database ij(CONNECTION1) select * from fred; ERROR 42X05: Die Tabelle/Ansicht 'FRED' ist nicht vorhanden.- get German error messages for Derby errors ij(CONNECTION1) localizeddisplay on; ij(CONNECTION1) values current_date; 1 -- November 8, 2007 - IJ localizeddisplay US english error messages 1 row selected - IJ locale rowcounts: US english ij(CONNECTION1) connect 'jdbc:derby:defaultLocaledb;create=true'; ij(CONNECTION2) select * from fred; ERROR 42X05: Table/View 'FRED' does not exist. - get US english error messages for Derby errors ij(CONNECTION2) localizeddisplay on; ij(CONNECTION2) values current_date; 1 -- November 8, 2007 - IJ localizeddisplay US english error messages 1 row selected - IJ locale rowcounts: US english % NOW I start a new IJ session and explicitly set the JVM default locale by specifying the variables: user.language user.region C:\java -Duser.region=BR -Duser.language=pt org.apache.derby.tools.ij vers?o ij 10.3 - IJ pt_BR message ij connect 'adf:adf'; ERRO 08001: No suitable driver- IJ pt_BR message ij connect 'jdbc:derby:defBRdb;create=true'; -create a database w/ JVM default (set: pt_BR) ij select * from fred; ERRO 42X05: A tabela/vis?o 'FRED' n?o existe. - get pt_BR messages for Derby errors ij localizeddisplay on; ij values current_date; 1 --- 8 de Novembro de 2007 - IJ localizeddisplay pt_BR 1 linha selecionada - IJ locale rowcounts: pt_BR ij localizeddisplay off; ij values current_date; 1 -- 2007-11-08 - IJ standard display (java format) 1 linha selecionada - IJ locale rowcounts: pt_BR ij connect 'jdbc:derby:deDEdb'; - NOW connect to the GERMAN database ij(CONNECTION1) select * from fred3; ERRO 42X05: Die Tabelle/Ansicht 'FRED3' ist nicht vorhanden. - get German error messages for Derby errors ij(CONNECTION1) values current_date; 1 -- 2007-11-08
Re: Are connectEventListeners supported with 10.3? [DERBY-3172]
FYI - opened JIRA issue *DERBY-3172 https://issues.apache.org/jira/browse/DERBY-3172 - connectionEventListeners* are in the test harness so I assume they are supported and should be working. Problem also appears to happen when using the EmbeddedDatasource Stanley Bradbury wrote: Is it true that the javax.sql.ConnectionEventListener is not supported by the ClientConnectionPoolDatasource? The attached program does not display the event messages when the network server is shutdown during the application run. To view the problem: 1) start network server (I specified -noSecurityManager to eliminate that added complexity) 2) run the program AND when the following message is displayed, stop the Network Server within 15 seconds: * now kill the NS while I sleep for 15 secs* The program will continue with the message: now try to use the connection after you killed the nS Only an exception is displayed: Exception in thread main java.sql.SQLException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation -specific condition for which there was no architected message at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source) at org.apache.derby.client.am.LogicalConnection.prepareStatement(Unknown Source) at DerbyNotification.main(DerbyNotification.java:61) Derby-941 lists the specifcation for both ConnectionEventListener and StatementEventListener but it appears that only StatementEventListener was implemented. If this is true are there plans to support ConnectionEventListeners? I hope I have just made a dumb error setting this up and someone can correct me. Any assistance will be greatly appreciated. Thank you, Stan
Re: Derby Issue ERROR XSDG1
Nitish Sinha wrote: Hi All, I am facing one problem in Derby could any one help me in this. The Error message which i am getting is Page(16586,Container(0, 1793)) could not be written to disk, please check if disk is full. failed . I am running the application in Windows XP,Java version 1.5 and Derby version is 10.0. Could any one tell me what is the reason of this issue,AS i restart the application it is working fine. Hope to get the reply from any one. Thanks in advance Regards, Nitish P. Sinha LT Infotech,Mumbai Phone: +91-22-56948484 Ext-6378 Mobile :9820748213 * Larsen Toubro Infotech Ltd.*_ __www.Lntinfotech.com_ http://www.lntinfotech.com/ This Document is classified as: LT Infotech Proprietary LT Infotech Confidential LT Infotech Internal Use Only LT Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ Also check for other reasons that a write to disk might have failed (e.g. automated backup thread has the files locked, etc.). And see if you might have encountered this JVM bug: http://issues.apache.org/jira/browse/DERBY-1280 The resolution to 1280 is: This issue was filed as PMR 37997,001,866 with the IBM JVM team and this has been fixed in the IBM 1.5.0 SR 3 release.
Are connectEventListeners supported with 10.3?
Is it true that the javax.sql.ConnectionEventListener is not supported
by the ClientConnectionPoolDatasource? The attached program does not
display the event messages when the network server is shutdown during
the application run. To view the problem:
1) start network server (I specified -noSecurityManager to eliminate
that added complexity)
2) run the program AND
when the following message is displayed, stop the Network Server
within 15 seconds:
* now kill the NS while I sleep for 15 secs*
The program will continue with the message: now try to use the
connection after you killed the nS
Only an exception is displayed:
Exception in thread main java.sql.SQLException: A network protocol
error was encountered and the connection has been terminated: the
requested command encountered an unarchitected and implementation
-specific condition for which there was no architected message
at
org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
Source)
at
org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at
org.apache.derby.client.am.Connection.prepareStatement(Unknown Source)
at
org.apache.derby.client.am.LogicalConnection.prepareStatement(Unknown
Source)
at DerbyNotification.main(DerbyNotification.java:61)
Derby-941 lists the specifcation for both ConnectionEventListener and
StatementEventListener but it appears that only StatementEventListener
was implemented. If this is true are there plans to support
ConnectionEventListeners?
I hope I have just made a dumb error setting this up and someone can
correct me. Any assistance will be greatly appreciated.
Thank you, Stan
import java.sql.*;
import javax.sql.*;
import javax.sql.ConnectionEvent;
public class DerbyNotification implements javax.sql.ConnectionEventListener
{
public void connectionClosed(ConnectionEvent arg0)
{
System.out.println(Connection closed happened);
}
public void connectionErrorOccurred(ConnectionEvent arg0)
{
System.out.println(Connection error happened);
}
public static void main(String args[]) throws Exception
{
ConnectionEventListener listener = new DerbyNotification();
// org.apache.derby.jdbc.ClientConnectionPoolDataSource40 ds = new
org.apache.derby.jdbc.ClientConnectionPoolDataSource40();
org.apache.derby.jdbc.ClientConnectionPoolDataSource ds = new
org.apache.derby.jdbc.ClientConnectionPoolDataSource();
Connection conn = null;
ds.setDatabaseName(sampleDB;create=true);
PooledConnection pooledCon = ds.getPooledConnection();
conn = pooledCon.getConnection();
pooledCon.addConnectionEventListener(listener);
DatabaseMetaData md = conn.getMetaData();
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
System.out.println(got connection now sleep);
Statement st = null;
PreparedStatement ps1 = null;
st = conn.createStatement();
try
{
st.executeUpdate(drop table TAB1);
}
catch (SQLException x)
{
System.out.println(no table exists);
}
System.out.println(now kill the NS while I sleep for 15 secs);
Thread.sleep(15000);
System.out.println(now try to use the connection after you killed
the nS);
ps1 = conn.prepareStatement(CREATE TABLE TAB1(COL1 INT NOT NULL));
ps1.executeUpdate();
conn.commit();
System.out.println(done);
}
}
Re: [jira] Commented: (DERBY-3109) Nonexistent property derby.database.defaultAccessMode shown in Developers Guide: User Authentication examples
Hi Kim - Sorry for the delay in responding - have been really distracted of late. The update looks good - I've posted my 'thumbs up' in JIRA. Kim Haase (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537695 ] Kim Haase commented on DERBY-3109: -- This patch has been available for a couple weeks, Stan -- do you still consider the issue worth fixing? If so, would you mind reviewing the patch and letting me know if it needs further fixes? Thanks very much. Nonexistent property derby.database.defaultAccessMode shown in Developers Guide: User Authentication examples - Key: DERBY-3109 URL: https://issues.apache.org/jira/browse/DERBY-3109 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.1.2.1, 10.1.3.1, 10.2.2.0, 10.3.1.4 Reporter: Stan Bradbury Assignee: Kim Haase Attachments: DERBY-3109.diff, rdevcsecure125.html The property name is: derby.database.defaultConnectionMode - this is listed correctly in the rest of the document.
Re: Requiring Java 5 compiler
I am concerned that this proposal includes dropping support for J2ME from Derby.I would like to see a standard vote if this does mean dropping the J2ME platform. IMHO it would also be good to poll the User community specifically about the use of J2ME to determine if such a change will leave some applications without an upgrade path. Rick Hillegas wrote: Rick Hillegas wrote: I would like to start writing Derby code which makes use of Java 5 features. More specifically: 1) I would like to take advantage of the Java 5 extensions for ease-of-use and stronger type checking. 2) I would like to be able to write regression tests which verify that user-written Java 5 code runs correctly as Derby functions and procedures. Would anyone object to our requiring that developers use a Java 5 or later compiler to build Derby? I believe that we would still require the presence of the 1.4 libraries and the expectation would continue to be that the compiler must compile down to 1.4 classes. Thanks, -Rick Discussion on this thread has died down so I would like to summarize what has been said so far: a) Java 5 source can't be compiled down to 1.4 class files. This means that any code which is necessary for Derby to operate must be 1.4 source. This means that mandatory code cannot take advantage of Java 5 features such as enums, generics, annotations, and varargs. b) The CDC small device platforms require 1.4 level class files. Java 5 class files will not run on CDC platforms. c) There is no problem with using the Java 5 compiler to compile 1.4 source into 1.4 targets. This already works today for those of us whose default compiler is Java 5 or Java 6. d) Java 5 is available on all likely development platforms, including Windows, Linux, Mac OS X, and Solaris. e) If we required Java 5 (or higher) in order to compile Derby, then we could use Java 5 features in optional engine code and in optional tests. I propose that we require Java 5 (or higher) in order to build Derby. If there are no objections and no further discussion, then I intend to call a lazy consensus vote on this proposal. Regards, -Rick
Re: Embedded mode: multiple connection read-only Db
Lu, Chris (NIH/NLM/LHC) [C] wrote: Dear Sir: I run into Derby last week and found it is very nice and easy to use. Especially with embedded mode makes it easy for software need to be distributed. However there are two features that I can’t found in Derby: 1). Multiple users (connections) Multiple connections are only provided for embedded Derby Server (not the pure embedded mode, org.apache.derby.EmbeddedDriver). Please correct me if I am wrong. 2). Read-only Derby provide a way for running on read-only media. However, does not provide a flag to set the database to read-only. In our application, we store all data in the database and don’t expect/want the end users to modify it after we distribute the software. Currently, we are using Hyper-Sonic SQL database. HSqlDb is also developed in 100% Java and don’t provide multiple connection for embedded mode with R-W mode. However, multiple connections are allowed when the flag of “read-only” is set to “true” in the embedded mode. Very nice and useful feature. Just wondering if Derby plan to provide the same features in the near future. Thank you very much and have a nice day! n Chris, Ph.D. n Sr. Systems Architect n Lockheed Martin/MSD/NLM/NIH Hi Chris - Regarding 1: I've talked to many people familiar with Client Server databases who read that 'embedded Derby can only be accessed from within a single JVM' and take this as meaning it is single user. This is not true. You can establish as many connections as you wish from within the same Java program/JVM environment. It is multi-threaded and locking prevents connections from stepping on each other. Please see my attempt to address this confusion in the section Is embedded Derby a multiuser database? at: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408bradbury/#cs_multi http://db.apache.org/derby/derby_downloads.html Regarding 2: The easiest way would be to place the database in a jarfile. Jarfiles are read-only even when deployed to read-write media. Accessing databases in a jar require use of special connection URL. Another way to implement read only is to enable auththentication and only give the users the access information to the read-only account(s). This works when the database is implemented in any architecture. You will want to define the required properties as database properties in the same manner as described in the section What are the steps needed to implement user authentication and authorization at: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408bradbury/#cs_authenticate Granted this is not as easy as flipping a switch or jaring up a DB but eliminates the possibility that someone unjars the database or unflips the switch. Hope this helps
Re: [VOTE] Øystein Grøvlen as a commi tter
+1 Glad I got back from vacation in time to vote - good work Øystein Rick Hillegas wrote: Please vote on whether we should make Øystein Grøvlen a committer. The vote will close at 5:00 pm San Francisco time on Tuesday August 28. Since 2005, Øystein has been submitting patches, fielding questions on the Derby mailing lists, and mentoring student contributions. He contributed heavily to the LOB improvements in the new 10.3.1.4 release of Derby. His patches include the following: DERBY-230Schema already exists when creating a table DERBY-298rollforward will not work correctly if the system happens to crash immediately after rollforward backup. DERBY-555Unable to restart after disk is full DERBY-1691 jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6 DERBY-1893 Convert largedata/lobLengthTests.java to junit DERBY-2100 Convert derbynet/prepStmt.java to Junit DERBY-2102 JDBC.assertFullResultSet should handle byte arrays DERBY-2347 Add code to support request and return of locators over DRDA DERBY-2495 Create framework for calling locator related stored procedures from client DERBY-2496 Implement Blob support for Locators DERBY-2519 Clean-up in BlobClob4BlobTest DERBY-2540 Restructure code for Blob/Clob length in client to prepare for locator implementation DERBY-2695 Add locator support of soft upgrade to 10.3 DERBY-2770 testBlobAfterCommit(jdbcapi.BlobClob4BlobTest) fails with 'Unexpected SQL state. expected:XJ[073] but was:XJ[215]' DERBY-2789 DatabaseMetaData .locatorsUpdateCopy() should return true I would add the following: 1) His knowledge of the Derby codeline is extensive. 2) His knowledge of our relevant standards (SQL and JDBC) is extensive. 3) The quality of his code is outstanding. 4) His interaction with the community is polite, helpful, and generous. Regards, -Rick
Re: sample release announcement
Hi Rick - Two thoughts for what they are worth regarding this bullet: o Adds builtin language-based ordering and LIKE processing. Since you have to create a DB to specifically support this it might be best to say: o Ability to create databases that supports alternate collation sequences (non-UCS_BASIC). These databases support language specific ordering and LIKE processing. -- It also seems this might fit better in the Administration section since it has to be specified when the Db is created. And thanks for driving this release to completion. Rick Hillegas wrote: Here is a mock-up of the 10.3 release announcement. Please let me know how I can improve this. -- The Apache Derby project is pleased to announce a new feature release of Derby, 10.3.1.4. Apache Derby is a subproject of the Apache DB project. Derby is a pure Java relational database engine which conforms to the ANSI SQL and JDBC standards. Derby aims to be easy for developers and end-users to work with. Derby 10.3.1.4 can be obtained from the Derby download site: http://db.apache.org/derby/derby_downloads.html. Derby 10.3.1.4 introduces the following new behaviors: * Security o Restricts shutdown, encryption, and upgrade powers to the DBA. o Installs a default security manager for the network server. o Supports wire-encryption. * SQL o Adds builtin language-based ordering and LIKE processing. o Supports the dropping and renaming of columns. o Creates tables based on a query shape. o Makes some CREATE TRIGGER clauses optional. o Adds ANSI TRIM capabilities. * JDBC o Supports all JDBC methods on BLOBs and CLOBs. o Expands embedded support for autogenerated keys. * Performance and Memory Usage o Reduces CPU usage in embedded mode. o Improves IN list processing. o Introduces LOCATORS for network client LOBs. * Administration o Allows import/export of LOBs. o Enables client-side tracing without changing the application. o Supports XAResource.setTransactionTimeout. o Adds system procedure support for setting a user's connection level authorization. o Adds a system procedure to empty the statement cache. o Supports diagnostic VTIs with parameters. * Platforms and Testing o Removes support for JDK 1.3 and J2ME/CDC/Foundation 1.0. o Converts many tests to JUnit's assertion-based framework. Regards, -Rick
Re: [VOTE] 10.3.1.4 release
The DERBY-2892 regression will be a problem for one of the development groups I work with but they will not be upgrading to 10.3 soon. Depending on release timeframes they may even be able to jump directly to 10.4 - hopefully a DERBY-2892 fix will be forthcoming [the group is currently using 10.1]. So lets get 10.3 out the door : ) +1 Rick Hillegas wrote: Please test-drive the Derby 10.3.1.4 release candidate, available at http://people.apache.org/~rhillegas/10.3.1.4/ This candidate includes additional work done on the following issues: DERBY-2350 DERBY-2793 DERBY-2925 DERBY-2963 DERBY-2966 DERBY-2960 DERBY-2955 Please record your test results on the 10.3 release page: http://wiki.apache.org/db-derby/DerbyTenThreeRelease Also please vote on whether you accept this candidate as a Derby release. The polls close at 5:00 pm San Francisco time on August 8, 2007. Once again, thanks to everyone for all of the hard work to date! Regards, -Rick
[OT - votes] Re: again, another 10.3.1. release candidate?
Daniel John Debrunner wrote: Stanley Bradbury wrote: As I indicated with my [-1] vote to the 10.3.1.2 VOTE thread: I need the fix for Derby-2896 to be part of official 10.3 release - this requires that new release candidtate be created (presumably 10.3.1.3?) Just a gentle reminder, no-one can veto a release. Thus anyone's desires for a specific bug to be fixed do not impose any requirement on a release manager. It is ok for a release to proceed ignoring -1 votes as long as it has the required number of +1 PMC votes. Though, I think if a release does have -1 votes that it is wise for the release manager to consider them before putting the release on the mirrors. Dan. Of course. I mentioned my vote and stated the importance (to me) of having this fix in the context of this thread asking ..another release candidate?, nothing more implied.
Re: [VOTE] 10.3.1.2 release
[-1] for 10.3.1.2 I need the10.3 release to contain the fix for Derby-2896. As stated in that issue - this is show-stopper for the collation feature. This feature will greatly increase Derby 10.3's acceptance / usability in non-English speaking countries. Myrna van Lunteren wrote: Hi, I have now prepared a release candidate, 10.3.1.2 (build/revision 556213). Please download and test-drive this candidate, and document test results on the testing pages = = = SNIP = = = To vote: [+1] Make the release candidate (10.3.1.2 - (SVN 556213)) the official 10.3.1.2 release of Derby. [ -1] Do not make the release candidate the official 10.3.1.2 release. (List showstopper Jira entries) Thanks to everyone who worked on this release. Myrna
Re: 10.3 - to release or not to release?
Myrna van Lunteren wrote: Hi, I've been looking over the fixed and open bugs for the 10.3 release, and there is a lot of good stuff... However, there are also some worrying aspects: - There are a number of Critical bugs open, most without any indication of getting a fix. See: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10594priority=2resolution=-1 - There are a number of intermittent test regressions so we're not getting consistently clean test runs. Just look at the platform testing list to see this: http://wiki.apache.org/db-derby/TenThreePlatformTesting In addition, there are 7 items which never received any Buddy testing... Further, we still ran into a deterioration in the suites.All at one point, requiring running with extra memory on many systems, which was never addressed. - There are a largish number of open bugs, many of which are marked affects 10.3., i.e. affect the new functionality added with 10.3. On the other hand, it seems to me some of the current functionality, is eagerly awaited by the user community. A number of the critical bugs are not new with 10.3., or are related to security, which may, or may not affect a number of our users...And none of them have an owner... So, I intend to continue with my stated plan of generating a Release Candidate and call a vote next Monday, but I would suggest we plan for a bug fix release off the 10.3 branch to specifically drive down the number of bugs... Thx, Myrna Hi Myrna - Thanks for the through release report. I took a look at the critical bug list and am concerned about the regression that causes locking problems: DERBY-2892 https://issues.apache.org/jira/browse/DERBY-2892 - this is a regression of the DERBY-255 fix and, though it was introduced in 10.2, should be addressed quickly. Has anyone look at the checkin that might have caused the regression? DERBY-326 https://issues.apache.org/jira/browse/DERBY-326 (svn 405037). This also concerns me because I assume the problem is because of the collation differences between the SYS schema and the User Database - I am not upto date on this issue - can it be resolved? DERBY-2896 https://issues.apache.org/jira/browse/DERBY-2896 - It sounds like DatabaseMetaData calls will fail when TERRITORY_BASED collation is used. This will mean that many IDEs will not work with these databases. Since this is a new feature it will not break existing systems but will slow use of the feature.
Re: 10.3 - to release or not to release?
Myrna van Lunteren wrote: On 7/9/07, Stanley Bradbury [EMAIL PROTECTED] wrote: Hi Myrna - Thanks for the through release report. I took a look at the critical bug list and am concerned about the regression that causes locking problems: DERBY-2892 https://issues.apache.org/jira/browse/DERBY-2892 - this is a regression of the DERBY-255 fix and, though it was introduced in 10.2, should be addressed quickly. Has anyone look at the checkin that might have caused the regression? No one has signed up. DERBY-326 https://issues.apache.org/jira/browse/DERBY-326 (svn 405037). This also concerns me because I assume the problem is because of the collation differences between the SYS schema and the User Database - I am not upto date on this issue - can it be resolved? You must be meaning a different bug? Sorry, but I don't understand. I've been trying to figure out which bug you *could* be referring to, but maybe you can just tell me. DERBY-2896 https://issues.apache.org/jira/browse/DERBY-2896 - It sounds like DatabaseMetaData calls will fail when TERRITORY_BASED collation is used. This will mean that many IDEs will not work with these databases. Since this is a new feature it will not break existing systems but will slow use of the feature. Again, no one signed up. One of the aspects that I let weigh in on deciding to call a vote or to hold it up for these critical issues, is that no one *has* signed up. I can theorize based on past track records hope that certain people might step up to the plate, but as long as there's no firm assignment coupled with an indication from the responsible individual that it's going to be done within a reasonable time frame, I don't think it makes sense to hold up a release... Myrna Hi Myrna - Bad formatting on that last message. The reference to Derby-326 relates to DERBY-2892 (the first issue). A comment in DERBY-2832 suggests that the changes made for DERBY-326 caused the regression reported as DERBY-2832. I was hoping that someone knowledgeable about the performance improvements could quickly address this issue. My concern about comparisons between the SYS schema tables and the User schemas related to the second issue of DatabaseMetaData failures. I don't think there is anything for you to do at this point. The community needs to look at these and determine if they will be highly detrimental to the Derby release. I have no doubt that, if released with these problems, 10.3 users will encounter these issues sooner rather than later. After some testing I may raise these concerns in a separate thread. And thanks again for your very through risk-analysis that highlighted these (and other) issues. It shows you are very much 'on top' of the Release.
Re: Subselect Performance Problem
Francisco Trindade wrote: Bryan, I´ve downloaded derby 10.3.1 and executed the query, but unfortnuately its still taking a lot of time (20 secs). I wanted to send the query plan in this mail, but its currently being written in portuguese. Does anybody know how to change the default language debry its using to write the query plan? Thanks, Francisco Bryan Pendleton escreveu: pesagens1_.PESAGEM_ID=pesagem2_.PESAGEM_ID where (animal0_.ANIMAL_ID in ( ... 800 ids ...)) Quite possibly, you are being affected by DERBY-47: http://issues.apache.org/jira/browse/DERBY-47 Since we believe that this problem has been fixed in Derby 10.3, it would be wonderful if you could download the DERBY 10.3 beta release from http://wiki.apache.org/db-derby/DerbyTenThreeRelease and give it a try to see how it affects your query. thanks, bryan P.S. Myrna, I noticed that it was a bit hard to find a good hyperlink to the beta release. Perhaps you could put a link to the 10.3 beta on http://db.apache.org/derby/ and/or http://db.apache.org/derby/derby_downloads.html as those would be natural places to look? Or are we not supposed to do that because it's still a beta release? Hi - The 10.1 docs it says the following - it sounds like you might have to recreate the database? * /Database territory/ This is the territory associated with your database when it is created. By default, this is the same as the java system locale http://publib.boulder.ibm.com/infocenter/cscv/v10r1/topic/com.ibm.cloudscape.doc/ctools1004764.html#ctools1004764__rtoolsijtools91283. The database territory determines the language of database errors. Database territory To specify a database territory, use the /territory/ attribute on the URL connection when creating the database. Note: You cannot modify a database's territory after the database has been created. For information about database territories, see the Internationalization appendix in the /Derby Developer's Guide/.
Re: lock a table
John Embretsen wrote: ludoW23 wrote: Hi, I'm studying Apache Derby and I'd like to lock a table during a select for example. Is it possible? Yes, there is a LOCK TABLE statement you can use. Take a look at the manual Derby Developer's Guide, specifically this page: http://db.apache.org/derby/docs/dev/ref/rrefsqlj40506.html Hi - I want to add something to what John states because it has tripped me up in the past. The documentation for LOCK TABLE states: The table lock lasts until the end of the current transaction. This means it is important to set AUTOCOMMIT OFF so the lock is not released when the LOCK TABLE statement completes.
Re: Question about sample database and import/export examples
Kathey Marsden wrote: http://db.apache.org/derby/docs/dev/tools/rtoolsimport91458.html Shows examples connecting to a sample database. Is the database for these import/export examples supposed to be included with the distribution or is the expected schema published somewhere? Thanks Kathey Good catch. This is an artifact left over from a previous time and place (pre-Apache). It might be good to update the documents to refer to toursDB instead.
Re: What are 'Optimized jarfiles' ?
John Embretsen wrote: Laura Stewart wrote: From what I understand form John, what are in the BIN and LIB distributions are the same. I am not sure what was meant by optimized. Well, as I wrote in a comment to DERBY-2390, the so-called optimized jars (i.e. the non-debug jars, without extra line number information) are part of both the lib and the bin distributions. The non-optimized (debug) jars are in the lib-debug distribution only. In other words, optimized basically means smaller footprint (for example, derby.jar is almost 1 MB larger in lib-debug than lib for 10.2.2.0), because the classes in the optimized jars don't include extra debug information such as line numbers in stack traces. I don't know if the extra debug information has any negative effects other than increased file size. I too felt somewhat uncomfortable with the term optimized jars at first, but I think I'm getting used to it know that I know what it means ;) On 6/14/07, Stanley Bradbury [EMAIL PROTECTED] wrote: Am reviewing the Getting Started Guide and found a reference to 'optimized jarfiles' in the LIB distribution. Is this wrong or do the jarfiles in LIB now differ from the BIN distribution? Thanks for the information. Sometimes I miss discussions on new and improved features that get implemented and thought perhaps some great performance improvement was implemented.
What are 'Optimized jarfiles' ?
Am reviewing the Getting Started Guide and found a reference to 'optimized jarfiles' in the LIB distribution. Is this wrong or do the jarfiles in LIB now differ from the BIN distribution? The distributions are: • The bin distribution contains scripts, demonstration programs, and documentation. The optimized jar files are available in the lib distribution. • The lib distribution contains an optimized, small footprint set of the Derby jar files for deployment.
Re: Terminology question - are dblook, ij, and sysinfo Tools or Utilties?
Laura Stewart wrote: On 6/8/07, Kim Haase [EMAIL PROTECTED] wrote: In my experience, tool and utility are synonyms and can be used interchangeably. Of course, if we follow the elementary tech writing rule Always use the same word to mean the same thing, we ought to choose one of them and use it consistently, but that may be too much to ask in community-generated docs. The merger of the GS and WWD books does give you a chance to do it right for these, though! Which you use I think depends on whether you prefer Anglo-Saxon monosyllables or Latinate polysyllables. HTH, Kim Since we have an entire guide Derby Tools and Utilities Guide devoted to these, it seems to me someone, somewhere felt that there was a difference for Derby. I have seen them used interchangably too (and don't have a preference since I can claim heritage from both the Anglo-Saxons and Latins :-) but we should be consistent and use 1 term. Since we are so close to the release candidate, I am going to just leave things as they are and open a separate JIRA issue for changing this and making it consistent in the Derby docs. I just need some feedback from derby-dev before I open the issue. I'm hoping that someone will provide me with a rational for each term :-) Laura Laura Stewart wrote: I'm trying to be accurate in the Derby documentation when discussing dblook, ij, and sysinfo. Are these tools or utilities? Is there a difference between a tool and a utility? Should one term apply to all of these or should we use different terms depending on what it does? For example, one of these simply dumps info to the screen (sysinfo). Is that different than opening up a mini application (ij)? I'd appreciate your options on the correct term to use to describe each of these. I wouldn't worry about this for the 10.3 release but here is my two-cents. I think of a TOOL as something with broad functionality that you interact with and can be used, most times, to accomplish a variety of things. Hence I think of IJ as a tool because it allows you to do any number of things within the database. This seems consistent with the Dictionary definition of: something (as an instrument or apparatus) used in performing an operation I think of a UTILITY as something you have little interaction with but performs a task or operation, often providing information or simplifying a specific task. Since SYSINFO and DBLOOK are executed by issuing a single command and then they do-what-they-do then stop (no interaction) I think of them as Utilities. This kind of fits what the dictionary says: a program or routine designed to perform or facilitate especially routine operations (as copying files or editing text) on a computer HTH
Re: Can't upgrade from 10.1 to 10.3
Dag H. Wanvik wrote: Stanley Bradbury [EMAIL PROTECTED] writes: Am I missing something? Has anyone successfully done the following upgrade?: I am not able to perform a hard upgrade from 10.1 to 10.3 [am setting the ...PreReleaseUpgrade=true and using 10.3.0.0 alpha - (543348)]. When I attempt to hard upgrade a 10.1 DB that requires authentication and has three valid users none of the logons are allowed to upgrade. The error is: ij version 10.3 ij connect 'jdbc:derby:tstDB;upgrade=true;user=stan;password=xyzzy1'; ERROR 08004: User 'STAN' cannot hard upgrade database 'tstDB'. Only the database owner can perform this operation. This is because the database was created with an other effective user, which then became the database owner. If authentication was not enabled at the time of creation and no specific user given, the owner would be APP. The docs changes for DERBY-2264 warm against this gotcha. A work-around is to make APP a valid user, if it is not already one. With the new semantics for 2264 (patch 8) tying the enforcement to SQL authorization, users will hopefully know the database owner, so this trap is less likely. SNIP === Making APP a valid user did not work for me either. Prior to version 10.2 I am not aware of there being a DBO but I understand the system tables were owned by DBA so I created such a user and it appears to have worked but since there is no schema called DBA any SQL causes errors. Is there anyway for an end-user to tell whom the code expects the DBO to be? C:\Stan\L3\10.3\DBOjava org.apache.derby.tools.ij ij version 10.3 ij connect 'jdbc:derby:noUserDB;upgrade=true;user=DBA;password=DBA'; ij select columnnumber, columnname from sys.syscolumns where referenceid in (select tableid from sys.systables where ta blename = 'SYSTABLES') order by columnnumber; ERROR 42Y07: Schema 'DBA' does not exist ij set schema app; 0 rows inserted/updated/deleted ij select columnnumber, columnname from sys.syscolumns where referenceid in (select tableid from sys.systables where tablename = 'SYSTABLES') order by columnnumber; COLUMNNUMB|COLUMNNAME 1 |TABLEID 2 |TABLENAME 3 |TABLETYPE 4 |SCHEMAID 5 |LOCKGRANULARITY 5 rows selected ij exit; %%% Attempts w/APP %%% ij version 10.3 ij connect 'jdbc:derby:tstDB;upgrade=true;user=APP;password=APP'; ERROR 08004: User 'APP' cannot hard upgrade database 'tstDB'. Only the database owner can perform this operation.
Review - second installment: (DERBY-2390) DOCS - Merge Working with Derby and Getting Started Guide
Hi - This is the second installment of my review of the new Getting Started Guide. Again I'm posting these comments to the email thread but NOT adding a comment to the JIRA issue. You can add this message to DERBY-2390 if you like or simply summarize relevant points based on your decisions about the suggestions. Background and General recommendations: Thanks to Andrew's improvements of the scripts (.bat and .sh: Derby-1032, v 10.2.1) the scripts no longer require that JAVA_HOME be set and, though the scripts will now figure out the proper setting for DERBY_HOME (assuming the scripts have not been moved from DERBY_HOME\bin) I recommend we still document that DERBY_HOME be set for ALL methods of execution. With regard to the scripts; having DERBY_HOME set allows the discussion of adding the scripts directory to the PATH environment variable can reference DERBY_HOME\bin. In addition the changes I suggest below count on java being in the system/user PATH. All the examples shown require the 'java.exe' be in the system/user PATH and this should be clearly stated and a check added to replace that of JAVA_HOME. I recommend something like this: == Related Text substitutions == Section: To check the Derby system configuration Change item 1 ... Replace: 1. Verify that the JAVA_HOME environment variable is set and points to a JDK version 1.3 or higher. Open a command window and run the command java -version [ SYSTEM SYNTAX TABLE: Unix and Windows] ... With: 1. Verify that the java executable, version 1.4.2 or, higher is in your command execution PATH by opening a command window and running the command CODE java -version /code [NOTE TO AUTHOR: this command is the same on all platforms so the SYSTEM SYNTAX TABLE can be removed. The example of output presented is fine, just change the reference to 1.3 (and all other references) which follows, as mentioned previously. Section: Setting the environment variables ... Replace: item: 3. Set the JAVA_HOME environment ... ... With: 3. Be sure the java executable is in your command execution PATH OR .. just remove item #3 altogether... NOTES TO AUTHOR: Be sure to search for and REMOVE other reference to setting/checking JAVA_HOME in the document. The first table in the document, 'Choosing a method to run the Derby tools and startup utilities' is key to the information presented later. Since many of my suggestions (both first and second installments) change or augment the information presented in the table, I thought I would provide a rough rewrite for it. Of course, I am not the author nor a good wordsmith so please use this as a guide and clean things up: == BEGIN of TABLE Suggestion = ++ COLUMN 1: Method ROW 1 Run the tools using the shell scripts provided ROW 2 Run the tools using the derbyrun.jar archive ROW 3 Run the tools using complete java command syntax or use Derby in a Java program ++ COLUMN 2: When to Use ROW 1 When you want to execute the tools with the least amount of typing and have a full Derby 'bin' software distribution available. ROW 2 When you only have the derby jarfile set available or you do not want to use the scripts provided. ROW 3 When you do not have the scripts and derbyrun.jar archive available or when you are interested in learning the full syntax of each command and understanding the details of setting up the execution environment. Also, anyone who will be programming with Derby will need to meet the requirements listed for this method. ++ COLUMN 3: Requirements ROW 1 To use the examples in this book, the DERBY_HOME environment variable must be set and both the java executable and the Derby scripts directory (DERBY_HOME\bin) must be in your command execution PATH. ROW 2 To use the examples in this book, the DERBY_HOME environment variable must be set and the java executable must be in your command execution PATH. The derbyrun.jar file must be in the same folder as the other Derby jarfiles. For more information see the syntax for the derbyrun.jar file. ROW 3 To use the examples in this book, the DERBY_HOME environment variable must be set and the java executable must be in your command execution PATH. You will need to know the full package name for the java class supporting the tool and the CLASSPATH environment variable must be set to include the required jarfiles. For details on setting the CLASSPATH, see Manually setting the CLASSPATH environment variable. = END OF TABLE = - - - - END: Related Text substitutions - - - - INCORRECT INFORMATION [note: derbyrun.jar does NOT need to be in CLASSPATH]: SECTION:Syntax for the derbyrun.jar file .. Replace: Adding the derbyrun.jar file to your CLASSPATH is equivalent to adding all of the Derby jar files to your CLASSPATH .. With: The derbyrun.jar file is a special jarfile archive that greatly simplifies invoking the Derby
Can't upgrade from 10.1 to 10.3
Am I missing something? Has anyone successfully done the following upgrade?: I am not able to perform a hard upgrade from 10.1 to 10.3 [am setting the ...PreReleaseUpgrade=true and using 10.3.0.0 alpha - (543348)]. When I attempt to hard upgrade a 10.1 DB that requires authentication and has three valid users none of the logons are allowed to upgrade. The error is: ij version 10.3 ij connect 'jdbc:derby:tstDB;upgrade=true;user=stan;password=xyzzy1'; ERROR 08004: User 'STAN' cannot hard upgrade database 'tstDB'. Only the database owner can perform this operation. If I execute the connect command a second time in the same IJ session I am allowed in but with a Soft Upgrade (even though the URL specifies ;upgrade=true).
Re: 10.3 blocker issue - DERBY-2728
Dag H. Wanvik wrote: Myrna van Lunteren [EMAIL PROTECTED] writes: Hi, We have a bump in our 10.3 release path - DERBY-2728. = = = = SNIP = = If we choose to tie enforcement to SQLAuthorization being on, I think this is a fairly small patch; the existing tests still have test cases for this (authentication + SQLauthorization), so they could be tweaked easily too. I expect most work would be to change the documentation (DERBY-2520). The release note for DERBY-2264 would need to change as well. I'd be willing to do this work if we choose that approach. I'd need a week; generally pushing releases less than 2 weeks seems not worth it, so I suggest a 2 week delay. DERBY-2728 speaks about making the semantics optional a *upgrade time*, though, which is another approach. This could imply some persistence of the fact that the database was upgraded and should have different semantics than a freshly created one, or use of extra properties. If someone volunteers to make such a solution, thats fine with me. Note that even if we tie enforcement to SQLAuthorization, some existing application may still be impacted, although presumably much fewer applications, since this is a 10.2 feature, and already implies a database owner concept and is probably less likely to be used in an embedded context (Kathey's concern). Thanks, Dag Should we make a release candidate while the fixing is in progress? Hi - Dag's suggestion seems like a best-approach to me. +1 It solves the problem with a 'fairly small patch' and can be done with minimal impact on the release date. The change will allow people who have not already set SQLAuthorization to test the impact of the new DBO role on their system and opt out of implementing it at this time. As Dag points out, people who have already stepped up to using SQLAuthorization will have identified the DBO account and designed the system accordingly so the change should be less dramatic. As a side note I think it good to encourage Derby users to plan for and implement the DBO role at their earliest convenience. Once the required changes are made and tested the flag can be set and the system will have the benefit of improved security. And the question about: Should we make a release candidate while the fixing is in progress? This seems like extra work for the Release Manager so, unless someone is aware of a critical need for a full release candidate build in the next week or two I would hold off. Of course I am not the Release Manager and it is her call.
Re: [jira] Commented: (DERBY-2390) DOCS - Merge Working with Derby and Getting Started Guide
Kim Haase (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498750 ] Kim Haase commented on DERBY-2390: -- This is a terrific job, Laura -- I think you've done a great job merging the manuals. These comments are on the individual sections. I don't think these answer every question you had, though. Let me see -- question 5 -- I think it would be good to update the output to 10.3 if possible, but getting the svn version right is probably not possible since code hasn't frozen. Question 7 -- I believe both mode and environment are used but in slightly different situations -- it might be worth adding the mention of mode to the Terminology section? I think configuration is used only in Deployment options -- not sure. = = = = SNIP === Stan's comments: Hi Laura - I'm posting these comments to the email thread but NOT adding a comment to the JIRA issue. You can add this message to DERBY-2390 if you like or simply summarize relevant points based on your decisions about the suggestions. The document looks good but I think it would be clearer to novice users to provide the following information / clarifications (in not particular order): 1) It looks like Kim has flagged the references to JDK 1.3 which is no longer supported in this release. The info from the WIKI states: 10.3 Platforms : Minimum JDK support will change to JDK 1.4.2 for J2SE CDC/Foundation 1.1 for J2ME. (Removes support for JDK 1.3 and J2ME/CDC/Foundation 1.0) - DERBY-1982 o) Laura is correct raising issue 6: I don't think that we do a good job of describing what the Network Server is. And I agree with Kim's suggestion: Deployment options - Here, probably, is where Network Server needs to be defined. IMHO the Deployment options section of the Getting Started Guide has never been right. The GS should only introduce the two basic options: Embedded and Server / Network Server. Any more gets you into the deep weeds really quickly. Here's a basic 'Getting Started' replacement for this section: Begin of Replacement === Before you install Derby, you should understand the system requirements and two basic frameworks provided. Basic Frameworks Provided The Derby software distribution provides two basic frameworks (also referred to as 'deployment options'). The simple embedded framework and the Derby Network Server framework. o Embedded is used to refer to Derby being started by a simple single-user Java application. In this framework Derby runs in the same Java virtual machine (JVM) as the application. Derby can be almost invisible to the end user because it is started and stopped by the application and often requires no administration. o Server (or Server based) is used to refer to Derby being started by an application that provides multi-user connectivity to Derby across a network. In this framework Derby runs in the Java virtual machine (JVM) that hosts the Server and applications connect to the Server from different JVMs in order to access the database(s). The Derby Network Server is part of the Derby software distribution and provides this type of framework for Derby. Derby also works well with other, independently developed Server applications. == END = o) The document would benefit from clarifying the three different 'command styles' shown in the 'Using the Derby tools and setup utilities'. Adding information to the 'Choose a method to run the Derby tools and startup utilities' seems like where this is needed. Also, for clarity and use the text provided below you will need to perform the following global changes on two of the three 'Method' columns in each table: Replace Method: Run the tools as standalone commands with: Run the tools using the command scripts Replace Method: Run the tools using the jar files that are located in the directory where the tools reside. with: Run the tools using the derbyrun.jar archive Intro Replacement suggestion [NOTE: you could instead add the three 'People/Programmers ... interested/have' sentences below to the 'When to Use' section of the table] There are several ways that you can run the Derby tools and startup utilities. with: This section discusses how to setup the system environment variables needed to run the Derby tools and utilities presented in the next section. Three ways to run each tools and utilities are shown. Choose the method that best fits your own personal needs and interests. Java programmers will probably be interested in learning the full command syntax show by the methods: '...using java command'. People who have a full Derby 'bin' distribution available, want to do a minimal amount of typing when running the tools and don't mind setting up a few environment variables upfront will like using the method '...shell
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade
Mike Madrigaling wrote: Dag H. Wanvik wrote: Hi, Stanley Bradbury [EMAIL PROTECTED] writes: I feel strongly that the restrictions implemented by DERBY-2264 must be tied to sqlAuthorization (or a new property of it's own) being turned on. The restrictions need to be optional at upgrade otherwise I understand your concerns. I addressed the upgrade issue several times in the discussion of this issue, but felt the community preferred the semantics which are currently implemented, landing on the side of a sensible secure-by-default behavior. Options: - label this a major release (11.0), lowering the expectancy for a painless upgrade with users. - postpose the 10.3 release and change the semantics to something else (tie enforcement to sqlAuthorization, introduce new property to turn this checking off (default on) or vice versa) - release it as it stands, but make a follow-up release with some knob to allow users to disable it; making sure to call this out in release notes. Note: since hard upgrade is among the operations restricted, users would likely (although not necessarily) get some hint of the issue early on ;) - pull the feature from 10.3 (I'd love to avoid that ;) - others? We need to decide pretty quick; this is a bit late in the game.. What say others? I agree. Let's somehow mark this issue as a blocker for the 10.3 release. I am not saying a change is necessary for the release, only some consensus on the right approach. It is not clear to me that the issue was fully understood, or noticed by the community at that point. I am ok with delaying the release get discussion/consensus on this issue. Thanks, Dag the feature will, by default, break compatibility for some applications using connection based authentication. Put simply, removing the ability for any user to shutdown or upgrade a database will cause failures in systems that depend on that functionality. I am certain that many Derby users like the near-zero-admin nature of the old authentication system. This feature introduces an administrative account. Dag originally suggested the feature be tied to sqlAuthorization (thank-you, Dag) when he noted that the patch caused some tests in derbyall to fail. Now that I have had time work with the feature and better evaluate the impact I see this as necessary for compatibility. This issue will be logged in JIRA before long but I chose to begin the discussion outside of JIRA to increase mailbox visibility. Any opinions - agreements/objections? I'll open a LIRA blocker issue on this later today (after all the meetings are over *whew*). I'll use the Title/Summary: Make DO restrictions from Derby-2264 optional at upgrade. I do not believe that existing Derby Users are aware of this change and I think the impact of will have is greater than anyone suspects. For instance, it appears that if ';upgrade=true' is hardcoded in the connection URL that only the DO account will be able to access the database. I suspect there are other issues like this as well. I will also add some additional information and suggest that as a sub-task (or super task - is that possible?) be added regarding deciding as a community how we will introduce changes like this. By 'like this' I mean changing previous behavior. More to the point is; defining a deprecation process that allows the Derby user-base to obtain a new release, assess the impact of 'changes' (the Release Notes will be the introduction of these issues for many users) and, by making the changes optional (activated by a property), allow applications that require significant rework to upgrade then begin work on what maybe several months to a year of coding and testing to become compliant with the behavior.
10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade
I feel strongly that the restrictions implemented by DERBY-2264 must be tied to sqlAuthorization (or a new property of it's own) being turned on. The restrictions need to be optional at upgrade otherwise the feature will, by default, break compatibility for some applications using connection based authentication. Put simply, removing the ability for any user to shutdown or upgrade a database will cause failures in systems that depend on that functionality. I am certain that many Derby users like the near-zero-admin nature of the old authentication system. This feature introduces an administrative account. Dag originally suggested the feature be tied to sqlAuthorization (thank-you, Dag) when he noted that the patch caused some tests in derbyall to fail. Now that I have had time work with the feature and better evaluate the impact I see this as necessary for compatibility. This issue will be logged in JIRA before long but I chose to begin the discussion outside of JIRA to increase mailbox visibility. Any opinions - agreements/objections? - Stan
Re: Row level locking
Umakanth Srinivasan wrote: No Iam not performing anything with respect to AutoCommit. I observed that this problem is related to the isolation level. In MySQL the problem did not occur. When I checked the default isolation level of MySQL it is REPEATABLE_READ, in Derby it is READ_COMMITED. Hope I must have the AUTOCOMMIT set to on. My only point is that locks are released at commit or rollback and with AUTOCOMMIT ON a commit is issued at the end of the execution of a statement. Thus I find using SELECT ... FOR UPDATE ... most effective with AUTOCOMMIT OFF.
Re: Row level locking
Umakanth Srinivasan wrote: Mode: Embeded I was trying to generate sequence keys with my code, and I faced issue in row level locking First, I locked my sequence keys holding table ( a table which says what is the next key for a specific table), with the FOR UPDATE OF column name keyword. Second, Then updating the table by incrementing the existing value, and getting the updated value. With print traces in my code I found that when a select query locks a particular row, and then before the next update, another connection is allowed to make a select on the query and get the same value. Am I missing anything here. Are you turning off autocommit before performing SELECT ... FOR UPDATE OF ... ?
Re: ERROR XSLA2: System will shutdown, got I/O Exception while accessing log file
Hi - It looks like Derby is trying create a new logxx.dat file (method switchLogFile) and is failing to do so. Check for things that would prevent file creation like limited disk space, limited open files, etc. It is unlikely but also check that the number being assigned to the logfiles is not reaching the limit: 4294967295 More info at: http://issues.apache.org/jira/browse/DERBY-101 ERROR XSLA2: System will shutdown, got I/O Exception while accessing log file. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java) at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java) at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java) Farid subhan wrote: Hi, I am a derby user. I get the following error message very rarely when there is a persistence storage error. The error code XSLA2 refers to System will shutdown, got I/O Exception while accessing log file. I donot get any other information from this error. Can you please help me find out the root cause of this and how can i avoid this error in future. thanks and regards, Farid. ERROR XSLA2: System will shutdown, got I/O Exception while accessing log file. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java) at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java) at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.flush(BaseDataFileFactory.java) at org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java) at org.apache.derby.impl.store.raw.data.CachedPage.clean(CachedPage.java) at org.apache.derby.impl.services.cache.CachedItem.clean(CachedItem.java) at org.apache.derby.impl.services.cache.Clock.rotateClock(Clock.java) at org.apache.derby.impl.services.cache.Clock.findFreeItem(Clock.java) at org.apache.derby.impl.services.cache.Clock.create(Clock.java) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java) at org.apache.derby.impl.store.access.btree.LeafControlRow.Allocate(LeafControlRow.java) at org.apache.derby.impl.store.access.btree.LeafControlRow.splitFor(LeafControlRow.java) at org.apache.derby.impl.store.access.btree.BranchControlRow.splitFor(BranchControlRow.java) at org.apache.derby.impl.store.access.btree.BTreeController.start_xact_and_dosplit(BTreeController.java) at org.apache.derby.impl.store.access.btree.BTreeController.doIns(BTreeController.java) at org.apache.derby.impl.store.access.btree.BTreeController.insert(BTreeController.java) at org.apache.derby.impl.store.access.btree.index.B2IController.insert(B2IController.java) at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java) at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java) at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java) at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java) at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java) at org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:69) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:272) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2060) at org.jpox.store.StoreManager.insert(StoreManager.java:733) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3304) at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4397) at org.jpox.state.StateManagerImpl.getExternalObjectId(StateManagerImpl.java:1300) at org.jpox.state.StateManagerImpl.getObjectId(StateManagerImpl.java:1184)
Re: Page could not be read from disk
Jessie Lee wrote: --- SNIP --- Hi, Stanley, Thanks for the reply. I got the following error from derby.log. I tried to restart the database and kept getting the same error. I guess the database is corrupted? Is there a way to fix the database? Thanks, Jessie java.io.EOFException at java.io.RandomAccessFile.readFully(Unknown Source) at org.apache.derby.impl.store.raw.data.RAFContainer.readPage(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source) at org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity (Unknown Source) at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source) at org.apache.derby.impl.services.cache.Clock.find(Unknown Source) at org.apache.derby.impl.store.raw.data.FileContainer.getAllocPage (Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainer.getAllocPage (Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getAllocPage (Unknown --- SNIP --- Hi Jessie - There is something wrong with file on disk. Note the exception is thrown executing the JAVA method java.io.RandomAccessFile.readFully caused by the end of the file (EOF) being reached unexpectedly. It would be good to check your disk and system logs for reports of Disk or I/O problems. Since you can't even get the database to boot it is time to recover the database from backup or rebuild the database.
Re: Page could not be read from disk
Jessie Lee wrote: Hi, I received the following SQLException while access my database (started successfully). Is this an indication of my disk corruption or database corruption? Thanks, Jessie Caught SQLException: Page Page(62342,Container(0, 3584)) could not be read from disk. I would expect there to be more information in the derby.log. The full exception chain should provide additional information. If this keeps happening and indicates the same page each time there may be corruption. You can check your table using SYSCS_UTIL.SYSCS_CHECK_TABLE() see: http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
Re: a client can crash connections of another client!
Quartz wrote: Hi, Using 10.2.2.0. Critical bug. Steps to reproduce: 1-Start a NetworkServerControl 2-Start a 1st client (sqlworkbench/J), show some rows of some db, table X (stay connected) 3-Start a 2nd client (sqlworkbench/J), show some rows of some db, table X. 4-disconnect 2nd client 5-redo the 1st client query (refresh) You get a non architected message, sqlstate 58009, db errorcode -4499. In derby log, I see a shutdown of the database, and a restart. I don't care how badly and corrupted a client connection can get, nor if the client connection is a bug in any client. Such corruption should never destabilise a server, certainly not other clients connections. It may be that the client tries to shutdown the DB, but it shouldn't have such priviledge since it is a client, NOT over an Embedded connection. Thanks for fixing this as quickly as possible. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail I think what you have run afoul of the fact that a client connection can shutdown the database thus ending the sessions of all currently connected users. A client application should never issue a database shutdown. The new security features implemented in version 10.3 will prevent a client from being successful should it attempt this. Please checkout 10.3 and see if the security manager changes do not address your concern. The specifications can be found attached to these issue: Shutdown privilege work: https://issues.apache.org/jira/browse/DERBY-2264 Security with Network Server: https://issues.apache.org/jira/browse/DERBY-2196
Re: [VOTE] Accept NetworkServer system tests contributed by IBM
+1 Jean T. Anderson wrote: As required by the ASF ip-clearance process in the Incubator [1], please vote to accept the NetworkServer system tests contributed by IBM that are attached to the following Jira issue: https://issues.apache.org/jira/browse/DERBY-2248 I'll close this vote on February 26, 2007, at 5:00pm Pacific time. regards, -jean [1] http://incubator.apache.org/ip-clearance/index.html
Re: The size of caches for dataDictionary
Yifan wrote: I have looked into the code for data dictionary. In the source code, there are some caches for tables or columns. One thing I am a little confused is the size of these caches. For example, if there is no DDL statement but only DML statement which manipulate on all tables, will the table cache keep all tables in memory or just part of them? If we do not have enough memory, will table belong to further DML statement being cached or not? Thanks Yifan The setting of pageCacheSize determines the number of pages that will be held in the data cache. New pages needed to satisfy the DML executed will be added to the cache until the pageCacheSize limit is reached. At this point the LRU pages in the cache will be removed to make room for newly referenced pages. Theoretically, if the pageCacheSize is larger than the size of all the tables and indexes in the database , all the the tables could become loaded into the cache and remain there until Derby is shutdown. HTH
Re: Need help on ORDER BY with expressions
Laura Stewart wrote: I need some help understanding an example that was posted in DERBY-264. The example is: SELECT i, j FROM t ORDER BY f ( j ) I understand all but f . Is that supposed to be function? It would be better if I could see a real world example of using this type of expression in the ORDER BY clause. Thanks! Laura = = SNIP = = Hi Laura - My guess is that you are correct and the f stands for 'any function name'.My recommendation is that the you use labels of the other non-SQL-command objects in the example like: SELECT col-1, col-2 FROM table1 ORDER BY function-identifier(col-2) Please check with whomever provide this example to be sure I am not missing something esoteric here.
Re: default character encoding
Nurullah Akkaya wrote: if i try to store a string in a char or varchar column what encoding does derby uses my vm or something else? i am trying to store international strings(utf-8 encoding). Nurullah Akkaya [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Blooby.com Tel: +1 (256) 270 4091 Hi - Derby stores data in a modified UTF-8 format without encoding information. The encoding is used to display the data and is managed by the UI which generally uses the encoding of the VM, however, some UIs allows this to be overridden - for instance when using IJ you can set the following: derby.ui.codeset Function Set this property to a supported character encoding value when using one of the Derby tools with a language not supported by your default system. See the Tools Guide for more information.
Re: Derby and 2007 Extended DST
Darryl Bowler wrote: Does anyone know if Derby is affected by this years Extended Daylight Saving Time? If so, is there a fix? You may find the following information useful. It addresses the issue for IBM OSs, VMs and Java applications. http://www-1.ibm.com/support/docview.wss?rs=636context=SSCRVPdc=D600uid=swg21249562
Re: Interpreting lock names?
James Synge wrote: I'm trying to debug a deadlock, and would like to better understand the names of the locks involved. For example: ROW, BUILD_REQUEST, (11,1) My guess is that this means that I'm dealing with a lock on a row in the BUILD_REQUEST table, and that it is probably row 1 in block (or page?) 11. Can anyone confirm this? Thanks, James Yes this indicates a ROW level lock on BUILD_REQUEST at page and row number (11,1)
Re: Issue with Derby Views
Hi -
Sure seems like a bug should be filed on this in JIRA, there is a test
case and everything needed. Would you or Suraj be willing to file a
JIRA bug? It is easy to do, information on doing so is at:
http://db.apache.org/derby/DerbyBugGuidelines.html
This way the problem will come to the attention of developers looking to
work with the codeline and possible be corrected.
Anuradha Weeraman wrote:
Hi All,
The following problem essentially has to do with accessing a view made
up of more than 300 tables. We found out that by reducing the number
of tables in the view, we managed to eliminate the problem. But when
we exceed approximately 300 tables per view, the issue started to
surface.
Below is the link to the discussion that has already taken on this
subject:
http://www.nabble.com/Can't-the-embedded-mode-of-a-Derby-database-boot-from-a-dual-JVMs-t2586621.html
Suraj (the reporter of the problem) has created a small application
which you can download from
http://www.nabble.com/file/4227/DerbyIssue.zip that recreates this
issue.
When I debugged the problem, I managed to reproduce the error with the
following exception:
ERROR XSDG3: Meta-data for Container
[EMAIL PROTECTED] could not
be accessed
The full stack trace is attached. The root exception seems to be:
java.io.FileNotFoundException:
C:\db\SampleDerbyDatabase\seg0\cd630.dat (Cannot create a file when
that file already exists)
When I debugged into RAFContainer.java, it seems to be throwing the
FILE_CONTAINER_EXCEPTION on line 1539. To give you some context:
--snip--
if (stub.exists())
{
try
{
boolean delete_status = privRemoveFile(file);
if (SanityManager.DEBUG)
{
if (!delete_status)
{
SanityManager.THROWASSERT(
delete of file ( + file + )
failed.);
}
}
fileData =
stub.getRandomAccessFile(canUpdate ? rw
: r);
readHeader(fileData);
}
catch (IOException ioe2)
{
// *** LINE 1539: THIS EXCEPTION IS THROWN ***
throw dataFactory.
markCorrupt(StandardException.
newException(SQLState.
FILE_CONTAINER_EXCEPTION,
ioe2, this));
}
// RESOLVE: this is a temporary hack
--snip--
I don't know enough of the Derby internals to know why it's doing
that. Would appreciate if someone could shed some light on this.
There are about 3400 files in seg0 folder and there was initial
speculation whether Derby was hitting the following JVM bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4189011
The JVM bug seems to be specific to Windows, but we managed to
recreate the issue on a Linux JVM, so I'm thinking that the issue is
not related to the JVM and is somehow Derby-related. But then, it ran
successfully on JVM 1.5.0_09, so I might be wrong.
ERROR XSDG3: Meta-data for Container [EMAIL PROTECTED] could not be accessed
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source)
at java.security.AccessController.doPrivileged1(Native Method)
at
java.security.AccessController.doPrivileged(AccessController.java(Compiled
Code))
at
org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown
Source)
at
org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown Source)
at
org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.find(Unknown Source)
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
Source)
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
Source)
at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown
Source)
at
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
at
Re: Drop a Table Column using ij
DerbyDo wrote: Running the Derby software that comes packaged with Sun Java Studio Creator 2.1 Trying to drop a column (which i added) from the Travel database table person I get an error that drop is bad (not recognized) My syntax: running windows XP SP2 aij prompt from Command line alter table person drop column conferencename cascade; I can do a select from the table using the column name which appears as: conference instead of conferencename for some reason. the column name: conferencelocation display as expected: conferencelocation from a select statemnet... What is wrong with my drop syntax?? Thanks Hi - See the following link for supported alter table syntax, ..drop column is not currently supported in Derby. http://db.apache.org/derby/docs/10.2/ref/rrefsqlj81859.html
Re: Can't the embedded mode of a Derby database boot from a dual JVMs
Jean T. Anderson wrote: Suraj Batuwana wrote: Also in client side i am getting the folloing error Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed junit.framework.AssertionFailedError: Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed I'm going out on a limb here because I know nothing about websphere, but I wonder if that container ... could not be accessed error has anything to do with file permissions on the data files that make up the derby database? Can you access that database using ij? If you're unfamiliar with ij, a quick intro is at http://db.apache.org/derby/papers/DerbyTut/ij_intro.html and example using the client jdbc driver in ij is at http://db.apache.org/derby/papers/DerbyTut/ns_intro.html#ij_ns_client . -jean Based on this method near the top of the stack trace (java.security.AccessController.doPrivileged1) it does look like this is a security problem. I believe that [EMAIL PROTECTED] refers to data file that Derby is attempting to open. Here are some ideas (some more far fetched than others): - Derby-1761: recent releases of IBM JVM v1.4.2 had a bug that produced access failures because property permissions were not being passed to methods being called. - Make sure this is local disk, not a share or network mount of some sort: E:\Cloud_Branch\TestDB\seg0\ - Make sure no other thread/process (e.g. copy/backup, compression, etc.) has the file locked. - Check the file size - I have seen XSDG3 errors when trying to open a corrupted database containing zero length DAT files. -HTH XSDG3: Meta-data for Container [EMAIL PROTECTED] could not be accessed at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code)) at org.apache.derby.impl.store.raw.data.RAFContainer.openContainer
Re: [VOTE] Laura Stewart as committer
Jean T. Anderson wrote: I propose that we add Laura Stewart as a committer for Derby. +1
Re: Working with Derby description on the Derby Docs Web page
Laura Stewart wrote: The following is the description of the Working with Derby manual that appears on the Derby Documentation Web page: http://db.apache.org/derby/manuals/index.html Is this description complete/accurate? Demonstrates how to use Derby in embedded and client-server configurations. Hi Laura - This is the short-and-sweet of it, accurate and brief. I think the description would be better if it contained a reference to the hands-on nature of the document but this is a minor nit. If you plan to update the page would you consider adding to the statement so it reads something like: Activities that demonstrate how to use Derby in embedded and client-server configurations. Thanks for checking
THANK YOU (again) to the WINNERS of the Derby 10.2 !!! Regression Search and Destroy Contest !!!
Hi Army, Yip and Prasenjit - I sent your bar of chocolate and a 'Contest Winner' certificate (suitable for posting on a cube wall) to your business location last week. Please check your paper-mail box and let me know if you have or have not gotten the award. Thank you again for your contributions. Stanley Bradbury wrote: Hi Army, Yip and Prasenjit - Yes! You have won the right to receive and do with what you wish: a bar of some of the finest dark chocolate available; Michael Mischer chocolates. === SNIP And most importantly, Thank you for your contributions to the Derby project. ---
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. +1
Re: [VOTE] Mamta Satoor as a committer for the Apache Derby project
Mike Matrigali wrote: This vote is for establishing Mamta Satoor (email: [EMAIL PROTECTED]) as a committer for Derby. Please vote +1 if you approve of Mamta as a committer. +1 Voting will close 5pm PST Thursday, November 9th. Since joining the project, Mamta has submitted many high quality, well documented patches. Most recently she worked on the Grant/Revoke feature in the 10.2 release. She has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe her expertise will be valuable going forward as a derby committer. /mikem
You may have already won: !!! Regression Search and Destroy Contest !!!
After much discussion and consideration our panel of judges have come to a decision regarding the winners of the v 10.2.1 Regression Search and Destroy Contest (and some really good chocolate). The winners are: First Place: Army for work on DERBY-1681, DERBY-1866, DERBY-1633 and DERBY-1315 Second Place: Yip for work on DERBY-1554 and DERBY-1652 and most effort expended Third Place: Prasenjit for work on DERBY-1633 and DERBY-1777 Will the winners please contact me directly with information on addressing the prize packages. Also let me know if you have preferences on the strength of the bars. The bars are all dark chocolate but come in various strengths like the lighter, dark chocolate (around 50% cacao), med dark chocolate (around 60% cacao) or dark, dark chocolate (around 70% cacao). Kathey Marsden wrote: We now have our panel of judges. Thanks to Stan, Rajesh and John for volunteering. Now all we need is an army of users to try their applications and flush all the bugs out of the product and documentation for 10.2. Please take a look and participate. http://wiki.apache.org/db-derby/RegressionSearchAndDestroy === SNIP ===
Re: [jira] Commented: (DERBY-408) Fix formatting of manuals in PDF output
Hi Kim - Please do open an issue on WWD (Working With Derby) and correct these problems. Having the lines run together as shown in your comment on 10/12 is awful. Several people contributed to the document in the form of input and reviews, I did the original contribution and take no offense to any changes members of the community deem appropriate (this change is more 'badly needed' than 'deem appropriate'). Halley has already done some clean-up (see: Derby-1394). I 'winged' the formatting in the codeblock sections in hopes it would be easier to read the longer interactive examples but I'm not certain it made a big difference. And now, of course, it is broken. I also noted Derby-1948 filed today (http://issues.apache.org/jira/browse/DERBY-1948 ) caused by the changes in the DEMO directory structure - the PROGRAMS folder did not exist in early builds of 10.2 - references to $DERBY_HOME/demo/subdir need to be changed to $DERBY_HOME/demo/programs/subdir. While you have the files open could you correct this as well? I don't know when I could get around to making even such a small correction. And; Thanks for the kind words about the document. Kim Haase wrote: Hi, Laura, Thanks for this comment. I've been wondering about the tagging in the Working with Derby book -- I think it is often unconventional (should output be in italics?? I don't think so). There is a DITA - to - XSL-FO problem, as you say, but possibly the formatting should be cleaned up too. This would be a separate bug, though. I could file it (and fix it) if you think it would be worth while. I'm sending this offline as I don't know who contributed the WWD book -- it's good to have it and the content is very useful -- and I don't want to hurt their feelings. Kim Laura Stewart (JIRA) wrote On 10/16/06 12:25,: [ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12442633 ] Laura Stewart commented on DERBY-408: - I don't believe that the documentation should use tags like bold b to force line breaks. Infact, in most cases there shouldn't be bold tags inside of codeblocks and syntax. Typically uppercase letters are used for the required SQL and lowercase letters for the variables such as index-name. Sometimes varname is used for the variables, which displays the text in italic. This sounds like a DITA - to - XSL-FO problem. === SNIP ==
Re: [VOTE] Army Brown as a committer
+1 (with enthusiasm) Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. = = = SNIP ==
Re: INPLACE_COMPRESS_TABLE query
Mayuresh Nirhali wrote: Hello, I was looking at Derby-606 and was able to reproduce the bug. I am working with a table of 30 million rows of the schema mentioned in the JIRA entry. I have a query regarding the size of the table before and after INPLACE_COMPRESS_TABLE command. After creating the table and inserting the 30 million records, a simple 'du -sk' shows the size as, 12008738testdb I exeucted INPLACE_COMPRESS_TABLE through ij and the size returned from the same command is, 12020239testdb Since, I have not performed any deletes, the reduction in the size is not expected. ofcourse, the testdb directory does not include derby.log. so, I am wondering about the little increase in the size. Is it in the form of some other logs ? Can someone throw some light on this increase in size ?? I would also appreciate any additional information on INPLACE_COMPRESS_TABLE. TIA Mayuresh, Hi - I'm going to make a guess that the increase is because in the initial dataload some of the free space reserved in each page (probably index pages) was utilized as new records were added and that the compress restored the default free space percentage for those pages thus spreading the records out over more pages. You can check my speculation by comparing the before and after sizes of the files for each table and index in the seg0 directory to see which are growing. Be sure to check that the number of before and after files are the same (that there are no d*.dat files waiting to be removed or log*.dat files that contain transaction information that need to be processed.). HTH
EXTENDED TIMEFRAME: Regression Search and Destroy contest
Remember the Derby 10.2 Regression Search and Destroy contest? To encourage more testing the Judges have decided to extend the contest so there is still time to enter a submission. (for information see: http://wiki.apache.org/db-derby/RegressionSearchAndDestroy). A 10.2 release candidate will be made available next week and a Vote begun after that. To encourage as much testing as possible the contest has been extended until the end of the yet-to-be-announced vote (the original deadline was today). The official end will be the end of the day when the vote for the candidate release is closed. Please take some time to shake down this candidate release and, if you find a regression, log it on the WIKI at the link above. Notoriety and chocolates could be yours !!
JARFILE procedures should be document in the Admin Guide not the Tools guide
At least that is my opinion (in the Subject line) but I wanted to raise this issue to the community for a broader perspective before opening a JIRA issue on it. Perhaps I'm missing something obvious. The are referred to as the 'database class utilities' which is I term I do not understand but does put them squarely into the Tools and Utilities Guide. The Tools and Utility Guide contains the section: Storing jar files in a database . This seems like an administration task to me. The text does not involve any kind of standalone utility or tool, but documents the syntax for using the built in procedures that must be run using the CALL statement. Of course, I guess the same thing can be said about the Import and Export procedures but at least they are in the schema SYSCS_UTIL as opposed to SQLJ. Any strong feelings against moving the section to the Admin portion of the Server and Administration Guide?
10.2.1 beta candidate testing results SLES 9 and Windows 2003 Server
Rajesh Kartha wrote: Hi, I have been running some tests on the 10.2.1.0 beta candidate and was thinking of a single place for posting all the results related to this round of beta testing. = = = SNIP = = = I've posted the results of my testing (running derbyall), with links to the bugs encountered at: http://wiki.apache.org/db-derby/TenTwoPlatformTesting Most, but not all, of the failures appear to be problems with the Test system or JVM specific. The following summarizes the derbyall test results by platform tested [NOTE about failure counts: some problems were encountered by multiple tests, e.g. The test system problem Derby-1221 was encountered 14 times]: SLES 9 Win2003 Win2003 ibm131ibm15 sun15 Tests Total629 693 693 Tests Passed 616 670 688 Tests Skipped 8 2 2 Test Failed621 3
Re: [jira] Created: (DERBY-1520) Document new SYSCS_DIAG tables
Laura Stewart wrote: Which derby docs need this change? Developers Guide? Reference Guide? On 7/17/06, *Stan Bradbury (JIRA)* derby-dev@db.apache.org mailto:derby-dev@db.apache.org wrote: Document new SYSCS_DIAG tables --- Key: DERBY-1520 URL: http://issues.apache.org/jira/browse/DERBY-1520 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.2.0.0 http://10.2.0.0 Reporter: Stan Bradbury See comments for DERBY-571 for initial documentation discussion. The new tables (mapped to the old Diagnostic VTIs) are: The old style syntax will remain in place for 10.2, but become deprecated. The tables to be implemented in this change are: SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable SYSCS_DIAG.STATEMENT_CACHE replaces org.apache.derby.diag.StatementCache SYSCS_DIAG.TRANSACTION_TABLE replaces org.apache.derby.diag.TransactionTable SYSCS_DIAG.ERROR_MESSAGES replaces org.apache.derby.diag.ErrorMessages The information about the tables can be found in the javadoc for the class listed above. That can be found at: http://db.apache.org/derby/javadoc/engine/ click on the org.apache.derby.diag link in the Packages table, then select each class, e.g. LockTable to see the info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Laura Stewart It seems to make the most sense to document these in the Server and Admin guide. This is where the corresponding vitual tables (e.g. LockTable) were documented with version 5.1. Also there is already a section on 'Built-in System Functions' in the Server and Admin guide in: crefsqlbuiltinsystemfunctions.html . These seem to me to be additional System Functions. Any other thought or opinions on this???
Problem with Policy file examples (codeBase specification)?
I'm spinning up on using Network Server with the default security
manager and have found an inconsistency in policy file syntax in the
Derby documents. The example policy files in the Developers Guide
differ from the example in the Server and Admin guide.
From what I've read the syntax in the Server and Admin guide is correct
for referring to a local files:
SYNTAX: grant codeBase file:d:/derby/lib/-
I've been using this syntax and know it works but see in the Spec this
syntax:
grant codeBase file:/${java.home}/lib/ext/
The Developers guide shows double slashes, almost like it were a URL or
Windows network reference:
SYNTAX:grant codeBase file://f:/derby/lib/derby.jar
Does anyone which is correct or if there are valid reasons for the
variations in a codeBase declaration?.
Here are the pages I am referring to:
http://db.apache.org/derby/docs/10.1/devguide/rdevcsecure871406.html
http://db.apache.org/derby/docs/10.1/devguide/rdevcsecure871422.html
http://db.apache.org/derby/docs/10.1/devguide/rdevcsecure871439.html
http://db.apache.org/derby/docs/10.1/adminguide/tadminnetservrun.html
Re: Derby Regression Search And Destroy Competition
Kathey Marsden wrote: ... SNIP .. So, inspired by the Mustang Regression Challenge [2] I would like to introduce the *Derby Regression Search and Destroy Competition*. This competition, in addition to finding regressions, will also incorporate fixing any regressions that are found. The winners will be: The top three developers or users who have made the greatest contribution toward a seamless upgrade to 10.2. If folks think this is a good idea, I will put up a Wiki for the competition, but here are the general guidelines: 1) Any action that exposes or resolves existing regressions, improves Derby compatibility with previous releases, or improves our documentation of known differences in 10.2 is considered. Below are a few examples: a) Find a new product regression from a previous Derby release and log it in Jira. b) Correct the derby info for existing issues to mark them as Regression if they are a regression from 10.1 or Existing Application Impact and Release Note Needed if they were intentional changes that might affect existing applications. c) Fix a product regression. 2) Three winners are chosen August 10 by impartial volunteer judge(s) whose decision is binding. 3) The winners get organic chocolate and of course glory and huge amounts of merit. (Contribution of other prizes is welcome, but wouldn't want to make the stakes so high the lawyers need get involved). Anyone else have ideas on this? Would anyone like to volunteer as judge? Judges would have to exempt themselves from the competition. Kathey [1] http://wiki.apache.org/db-derby/ForwardCompatibility [2] https://mustang.dev.java.net/regchal/ Since I'm pretty much exempt from the competition (how many doc regressions are there anyway?) I'll signup for being a judge , but there has to be at least one other volunteer so I don't get all the credit/blame for the results.
Re: [jira] Created: (DERBY-1483) Java Function defined with a BIGINT parameter invokes the method with a signature of method(long) rather than method(Long)
Daniel John Debrunner wrote:
Stan Bradbury (JIRA) wrote:
Example: define the function bigintToHexString to accept a BIGINT parameter
(see below) and reference the corresponding java method bigintToHexString
(shown below) that accepts a Long. Add the jarfile with the class to the DB,
setup the database classpath and invoke with the query shown.
Java Class:
import java.sql.*;
public class derbyJavaUtils
{
// bigintToHexString
public static String bigintToHexString(Long myBigint)
{
return myBigint.toHexString(myBigint.longValue());
}
As a related question, why would you want this to resolve to Long? Using
the primitive type long in this case will be more efficient, no need to
create a Long object. Your method could be re-written as:
public static String bigintToHexString(long myBigint)
{
return Long.toHexString(myBigint);
}
Dan.
Hi Dan -
I have no need to resolve to a Long, I expected that it would resolve to
a Long because the information on BIGINT in the manuals. It lists
java.lang.Long as the compile time type for BIGINT (though I must admit
to not understanding what a 'Compile time type' is).
As I understand it now, all Derby numeric datatypes that have a
corresponding primitive type will resolve to the primitive type when
passed as a parameter to a Derby java function or stored procedure. I
will get this information onto the WIKI so it is available for others to
reference, review and add to.
Thanks again for the help with this issue.
Re: [VOTE] 10.1.3.1 release
Andrew McIntyre wrote === SNIP === I will close this vote on Thursday, June 29 at 3:15 pm PDT. Please let me know if you need more time to inspect/test the release candidate and cast your vote. Thanks again to everyone who has helped out with the release. andrew +1 I have run derbyall with 10.1.3.0 on Linux SLES 9 (dual processor) using the SUN 1.5 JRE and the IBM 1.3.1 sp10 JRE - no failures (one test harness issue was filed) I ran derbyall with 10.1.3.1 (RC2) on Linux SLES 9 (dual processor) using the SUN 1.5 JRE - no failures
Question about WIKI anchors
I beginning a new section on the Wiki called HintsAndTips so am spinning up on the page layouts and markup format. I am using the WorkingWithDerby page as a template for the contents / links page and have run across something I don't understand. At the top of the page a number of anchors are defined. What are these and is there any reason I should define these or others on the HintsAndTips list? The section, with comment is: ## Please leave the anchors in place below -- pages on the Derby web site need to be updated to not reference them [[Anchor(Tutorials)]] [[Anchor(Courses)]] [[Anchor(Examples)]] [[Anchor(Demos)]]
Re: [VOTE] Suresh Thalamati as Derby committer
David Van Couvering wrote: This vote is for adding Suresh Thalamati as a committer to Derby. ==snip== [ ] +1 Make Suresh Thalamati a committer for Derby Thanks, David + 1
Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases
Mamta Satoor wrote:
Hi,
I have researched quite a bit on Derby-655 : getImportedKeys returning
duplicate rows in some cases. Here are my findings and 3 possible
solutions to the problem. After reading the mail, if someone can think
of any other way of solving this problem, then please share it.
SNIP ==
In the above sql snippet, when the join is made on SYSCONSTRAINTS,
SYSKEYS, and SYSCONGLOMERATES for primary key on table t2, the query
finds 2 rows in SYSCONGLOMERATES with the conglomerateid and it picks
both those rows. This is wrong and we need to somehow return only one
row from SYSCONGLOMERATES, eventhough there might be duplicate rows in
there for a given conglomerateid.
I have thought of following 3 solutions
1)Even if a foreign key's backing index qualifies as a duplicate
index, have foreign key backing index create its own conglomerate
rather than share an existing conglomerate. But this would mean that
system would have to maintain 2 identical conglomerates. This can
impact Derby's performance negatively, although I don't know how badly
because it might be rare that a user creates a primary key and foreign
key on identical columns.
2)Write a system function which will return just one row for all the
duplicate conglomerateids for a given constraintid and use that row in
the outermost select statement of metadata query for getImportedKeys.
Not sure how easy this would be to implement but I am leaning towards
this solution.
3)Do not create duplicate rows in sysconglomerates for duplicate
indexes. Instead have just one row in sysconglomerate to represent all
the duplicate indexes in sysconstraints. But that seems like more of
an enhancement rather than a bug fix to me. Current Derby code heavily
relies on having a row in SYSCONGLOMERATE for each of the indexes.
Thanks if you have made it this far :) I hope this mail is clear in
explaining the problem and the possible solutions. If anything is not
clear, then let me know and I can provide more information.
If anyone has any ideas about some other possible fix for the problem,
please let me know that too.
thanks,
Mamta
The table needs a primary key - besides making conglomerateid unique it
might be less invasive to add a system generated primary key to this
table. I personally avoid using tables without primary keys because you
can run into odd-ball situations like this where multiple records can be
identical and so it is not possible to get just one record.
With a primary key you can get a single record by adding a correlated
subquery to the query conditions that specify using the record with the
record with max or min value of the unique column. Say the unique key
column is conglomeratePK - the conditional would be:
select * from sys.sysconglomerates c1 where c1.conglomeratePK = (
select max(c2.conglomeratePK ) from sys.sysconglomerates c2 where
c2.conglomerateid = c1.conglomerateid);
Re: Feedback integrate/plugin_howto.html
Joe Dorocak wrote: Dear Derby-Dev, Regarding your article Using the 10.1 Core and 1.1 UI Derby plug-ins at URL http://db.apache.org/derby/integrate/plugin_howto.html#Installing+the+plug-i ns I have tried to install the Derby plugins twice now, without success. I checked the md5 sums for both derby_core_plugin_10.1.2.zip and derby_ui_plugin_1.1.0.zip. They were both OK. I unzipped them both into C:\eclipse, my ECLIPSE_HOME, as a result there are 3 new subdirectories under C:\eclipse\plugins: org.apache.derby.core_10.1.2 org.apache.derby.plugin.doc_1.1.0 org.apache.derby.ui_1.1.0 However, after restarting eclipse, Version: 3.1.2, Build id: M20060118-1600, Apache Derby does NOT show up in the menu when I right-click on my project. Additionally, under HelpAbout Eclipse SDKPlug-in Details, when I sort on Plug-in Id, org.apache.axis is followed by org.apache.lucene and NOT by org.apache.derby.core and the 2 other derby items, as I expected. I hope you can help me. If you want, I can provide a listing of the directory contents of the derby plugins, as well as a listing of the relevant plugin.xmls. Thanks in advance. Regards, Joe Dorocak [EMAIL PROTECTED] Hi Joe - You may have already seen this but your issue is very close to the problem posted by JavaJosh earlier with the same subject line. The archive of the begining report is at: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/[EMAIL PROTECTED] There were responses which I do not see in the archives yet so am pasting here in case it is of help: [EMAIL PROTECTED] wrote: Hi, From the output you've shown below it appears that you have the 3 plugins installed, however I'm not sure why you are having the problem. The version of Eclipse I have is 3.1.0. When I look at the configuration details of my installation it shows all three plugins in the registry as well as in the configured plugins section. I noticed it does not show the UI or Doc plugins in the registry section for you. Later today I'll install 3.1.2 and see if I run into the same problems you are. As a quick suggestion that might help, try restarting eclipse with the -clean option. eclipse.exe -clean Thanks, Susan Rajesh Kartha wrote: Can you also look in the workspace log file if there are any errors/exceptions. In your case the file should be: C:\bin\eclipse\workspace\.metadata\.log Any reason for not loading/starting the plug-ins will typically be written to this .log file. -Rajesh
Process Question: New demo code - Adding JAVA code and CLASS files [...demo\workingwithderby]
The final version of the Working With Derby document will be committed tomorrow. This will include the two programs covered in the document. Unlike the document that is being added to the derby-docs repository these will be added to the derby-code repository ( in trunk\java\demo\workingwithderby). There will be class files in this directory. I understand from a reliable source that I should not include the class files in the patch I prepare but that the programs need to be compiled as part of the build. I need guidance on how to get this done. Does someone manage the build files (it appears that ...trunk\java\demo\build.xml describes building the demo programs)? Should I make an attempt at setting up the build based on how the demo\simple is handled in this file? Any advice / cautions will be appreciated.
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Daniel John Debrunner wrote: The various versions of WWD at http://db.apache.org/derby/manuals/index.html#latest are out of date. The PDF version only has the first activity. Dan. Hi Dan - Thanks, I'll look into the PDF build problem - it should contain the first four chapters which have been committed. The HTML docs contains all four chapters so am hoping it is something simple with the PDF transform process. In the meantime you can use the verification copy of the PDF for Chapters 1-4 that is attached to Derby-913 - the download URL is: http://issues.apache.org/jira/secure/attachment/12325929/CheckCommitWWD-Ch1-4.pdf The final two chapters are near the end of the review period. I intend to submit the patch to be committed tomorrow barring new major issues. The initial draft without the changes from the review can be viewed by downloading: http://issues.apache.org/jira/secure/attachment/12326037/ReviewPDF_wwdCh5and6rv1.0.zip The changes are fairly minor - One: renaming the 'miscellanea' section and changing the links as described in my message to Jean: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/[EMAIL PROTECTED] Two: And rewritten two of the Activity notes as shown in: http://mail-archives.apache.org/mod_mbox/db-derby-user/200605.mbox/[EMAIL PROTECTED]
Re: [WWD] Review of Final Chapters (5 and 6)
I like the name - add mine to the votes for WorkingWithDerby. \Jean T. Anderson wrote: SNIP == What about naming the Wiki page WorkingWithDerby? -jean
Request for comments on deciding between implementing embedded or client-server - (was: [WWD] Review of Final Chapters (5 and 6))
Starting spin-off thread on derby-user and inviting derby-dev readers to participate - see the attached thread for the current state of the discussion. DERBY-DEV readers: please help centralize this discussion by replying and monitoring this topic on DERBY-USER. OVERVIEW: The ability to easily implement Derby in different architectures differentiates Derby from most other RDBMS systems. Helping people understand the benefits and costs of each of the Derby implementation architectures is important to the successfully using Derby. Please share your experiences regarding the pros and cons of using Derby in embedded and client-server architectures. Craig L Russell wrote: Hi Stan, When you get around to discussing architecture issues, you might make sure you get feedback from the derby experts. My understanding is that you can use the embedded Derby with both same-vm clients and outside-vm clients by starting the network server when you start the embedded database. Craig On May 3, 2006, at 2:21 PM, Stanley Bradbury wrote: John Embretsen wrote: === SNIP === quote 1 from Activity notes, p.6 (8) A client program is often created to allow database access and updates from multiple computers on the network. /quote I don't think this statement is correct. It is not the client program that allows access from multiple computers, it is the server framework that does this. Would you like to rephrase? quote 2 from Activity notes, p.6 (8) Derby's two architectures have caused confusion for some new Derby users. They mistakenly think that embedded is a single user configuration. Not true. The embedded driver supports multiple simultaneous connections, performs locking and provides performance, integrity and recoverability. /quote I think this is still confusing. I think you should add a comment saying that the embedded driver must *not* be used to access the same database from more than one JVM simultaneously. The multi- user capabilities you are describing are (as far as I know) only valid if all users use the same JVM/Derby system (i.e. the same instance of the embedded driver), or if no users using different JVMs/Derby systems access the same database at the same time. Hi John - Thanks again for your attention and feedback. Both suggestions are well taken. The sentence about the reason to create a client program is not well constructed and is inaccurate. I also see that it does not carry the message I intended and I will rephrase it. The other note is what I think of as an 'endorsement of the embedded architecture'. I included it to get people thinking / questioning along the lines you are, I have been successful in that regard. I think it an important endorsement to make because I have seen many people new to Derby avoid embedded without really thinking it through. It is my sense that the copious warnings about 'double booting' scares them away from embedded. After working with Derby for awhile these people see that the embedded driver fully supports their need and is a cleaner and faster implementation. I wanted to plant that seed of an idea. It is arguable that the topic does not belong in an introductory document at all because it deals with system architecture as well as the specific meaning of terms like 'single-user', 'client- server', 'networking' and 'interprocess communication'. Clearing up the confusion is out of the scope of this document. Your suggestion, however, has me thinking I should draft a short paper on the topic that can be referred to when questions like yours are raised and will begin working on this. Do you think this will help with the issue you raise? I hesitate to include the standard caution about access from multiple-JVMs as I perceive this as contributing to the mind-set that using the embedded driver is limiting. I would really like to hear your thoughts on this and maybe begin a new thread on the topic of when to use Network Server and when the embedded driver is sufficient. It seems there is enough in this topic for a lively discussion. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Hi Craig - You are correct. There is what has been termed the 'embedded server' architecture as well but this is well out of the scope of a introductory document like WWD. However, since I hope to spin-off a thread discussing the various implementation architectures this should be included there. And thanks for the suggestion on including derby-dev - even though this is an implementation architecture issue (hence more germane to derby-user) I think there are derby-dev people who will want to participate. I will cc derby-dev on this message and ask for input on this thread (I think this topic is worth the cross-post).
Re: [VOTE] Halley Pacheco de Oliveira as committer
+1 Jean T. Anderson wrote: This vote is for establishing Halley Pacheco de Oliveira as a documentation committer for Derby. Halley has translated the Derby Getting Started Guide and the Derby Reference to Brazilian Portuguese (DERBY-780, DERBY-1138) and tells me the Derby Server and Administration Guide is being worked on. Halley has submitted numerous patches to correct the English documentation (DERBY-1123, DERBY-1175, DERBY-1194, DERBY-1195, DERBY-1200, DERBY-1203, DERBY-1207, DERBY-1263, DERBY-1270). Voting will close 5pm PST Monday, May 8. [ ] +1 Yes, Halley should become a committer [ ] 0 I don't care. [ ] -1 No (Please give a reason)
Re: [WWD] Review of Final Chapters (5 and 6)
Jean T. Anderson wrote: Stanley Bradbury wrote: The final chapters or the Working With Derby are available for review SNIP === In chapter 6 you link to http://wiki.apache.org/db-derby/UsesOfDerby , and I think this is ok but that list kind of overwhelming with just a few pointers on how to actually use a product with Derby. I had pulled some of the links for the Quick Start page [1] from http://wiki.apache.org/db-derby/DerbyInstruction , which points to real materials on how to do things. I think with some improvement it might be a better candidate for linking to. I'll take a shot at reorgnizing the DerbyInstruction: 1) I think it needs a flatter structure that makes it easier to find a given product 2) I don't like the name DerbyInstruction -- I find it too hard to even remember it's there. What would be better? DerbyHowTo ? thoughts? -jean [1] http://db.apache.org/derby/quick_start.html#Next+Steps+for+Users Hi Jean - Thank you for pointing this page out - I like your suggestion but think it better to replace the main link at the beginning of the chapter (currently pointing to the 'Quick Start' page (QS)) with the more focused DerbyInstruction page (DI). What do you think? I would then demote, so to speak, the QS link to paragraph text where QS is mentioned (just before the location of the 'Uses of Derby' link (UOD)). I'd like to leave the text mentioning UOD and encouraging people to add to it but, after thinking about your comments, think that removing the link from WWD would be wise. People who are really interested can seek out the page but folks not sure where to go next won't be able to just click through to it. I agree it is a mixed bag but I do like it from a PR standpoint - it shows Derby is being adopted. That is to say: I like telling people about UOD at the end of WWD as they might be wondering where Derby fits within their environment. Though the links on UOD will not talk directly about Derby the number of entries show it is widely used. I think seeing this will provide a level of confidence that Derby can be used in real-life situations. And now onto you question: A better name for DerbyInstruction here are some off-the-top (if not off-the-wall) suggestions (I like DerbyHowTo as well): DerbyCookbook - CookingWithDerby - DerbyRecipes - DerbyRecipebook ImplementingDerby - RunningWithDerby - DerbyKnowHow
[WWD] Review of Final Chapters (5 and 6)
The final chapters or the Working With Derby are available for review and comment. Please take time to provide constructive feedback on Chapters 5 and 6 - the review period will last at least a week (until May 5). The first four chapters have been committed and are available in the documentation codeline. A PDF-format review copy of these chapters is also attached to DERBY-913 and a download link is provided below for those who like to perform a start to finish read of the document. Review copies of the document can be downloaded using the following URLs: New chapters 5 and 6: http://issues.apache.org/jira/secure/attachment/12326037/ReviewPDF_wwdCh5and6rv1.0.zip Committed Chapters 1 thru 4: http://issues.apache.org/jira/secure/attachment/12325929/CheckCommitWWD-Ch1-4.pdf Original Message Subject: [jira] Updated: (DERBY-913) [WWD] Proposal to create and add Working With Derby, an activity-based tutorial document, to the Derby documentation set Date: Fri, 28 Apr 2006 22:16:40 + (GMT+00:00) From: Stan Bradbury (JIRA) derby-dev@db.apache.org To: [EMAIL PROTECTED] [ http://issues.apache.org/jira/browse/DERBY-913?page=all ] Stan Bradbury updated DERBY-913: Attachment: ReviewPDF_wwdCh5and6rv1.0.zip ReviewSRC_wwdCh5and6rv1.0.zip Initial reveiw files (rv 1.0) for Working With Derby Ch 5 and 6 Please review and send comments to [EMAIL PROTECTED] Please code the subject line with '[WWD]' ReviewPDF_wwdCh5and6rv1.0.zip - Contains the generated PDF and the program files needed to perform Activity 4 (Ch 5) ReviewSRC_wwdCh5and6rv1.0.zip - The DITA source files to generate the review PDF === SNIP ===
Re: [jira] Updated: (DERBY-913) [WWD] Proposal to create and add Working With Derby, an activity-based tutorial document, to the Derby documentation set
Jean T. Anderson wrote: Stan Bradbury (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-913?page=all ] Stan Bradbury updated DERBY-913: Attachment: 4COMMIT_wwd_Ch1-4.diff 4COMMIT_wwd_Ch1-4.pdf Document patch submitted to be committed: FILE: 4COMMIT_wwd_Ch1-4.diff - the patch file: Adds Chapters 3 and 4 Updates Chapters 1 and 2 Updates build.xml to correct build problems on Linux FILE: 4COMMIT_wwd_Ch1-4.pdf PDF document generated from the above patch files. Can be used to review changes and additions. ... The patch is failing with hunk failures on the build.xml, which is a little odd since this is just the second patch and you're the only one doing patches right now: patching file build.xml Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #2 FAILED at 36. Hunk #3 FAILED at 104. Hunk #4 succeeded at 154 (offset -3 lines). 2 out of 4 hunks FAILED -- saving rejects to file build.xml.rej Did you 'svn up' your working copy before creating the patch? I'll email you the build.xml.rej separately. -jean Hi Jean - I think the 'svn up' might be the problem - I performed an 'svn co' to refresh my local copy prior to making the changes and creating the DIFF - would this sync up my copy? I will read up on these commands and may follow-up with more questions. I'm a newbie to the PATCH process so please bear with me. John pointed out a typ-O that I can also fix before creating the new patch. Should I delete the original DIFF file from the JIRA issue because it is not correct and should not be used?
Re: [WWD] LAST CALL - for comments: CH 3 and 4 Revision 1.1 review
John Embretsen wrote: Jean T. Anderson wrote: Over all I think this looks pretty good, Stan. Here are a couple minor suggestions. Page numbers referenced are the printed page. Page 5: Activity 2: Activity miscellanea I suggest simplifying this section title to something like Activity Notes so users who aren't native to English won't feel compelled to look miscellanea up in the dictionary. I agree... Page 7: Activity 3: Step 2 verify that the Java SDK is proper installed should be verify that the Java SDK is properly installed This may be of microscopic importance at this point in time, but: To make this guide more in line with current naming conventions in the world of Java (and to reduce the need for maintenance), I suggest not using Java SDK at all. The reason for this is that as of J2SE 5.0 (or 1.5 if you wish), the development kit has reverted back to the name JDK from Java 2 SDK (or J2SDK), and the runtime environment has reverted back to JRE from J2RE. See http://java.sun.com/j2se/1.5.0/docs/relnotes/version-5.0.html for details. So perhaps verify that the Java development kit is properly installed is better/more general? By the way, more on Java SE/EE naming here: http://java.sun.com/developer/technicalArticles/JavaOne2005/naming.html Also on Page 7: Activity 3, step 1: There is a space missing in set theCLASSPATH: -- And in addition Jean had stated: Page 11: Activity 3: Shutdown the Database Do you want to mention that nothing bad will happen if you don't explicitly shutdown the database? and that Derby will run recovery code on the next startup? If I were a new user, I would read The shutdown process puts the database in a consistent state and wonder if I would risk leaving the database in an inconsistent state if I didn't explicitly shut it down. = = = = = Thank you Jean and John - I will improve / correct these areas. I really appreciate the information on JDK vs SDK and move away from using either even though I do have a love for TLAs (Three Letter Acronyms). I was indulging in a bit of whimsy when I selected the word 'miscellanea' and can see how that would not 'play' well to a global audience (english as a second/third/.. language). I will avoid such word-play in the future (and rename the section in Ch 3 that also suffers from whimsy)..
Re: [jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
Oystein Grovlen - Sun Norway wrote: Bryan Pendleton wrote: 1) There are two basic configurations of interest here: a) In the simple Network Server case, the Network Server process is providing access to the database(s) over DRDA b) In the dual-access configuration, an application which has established embedded access to the database(s) is also providing networked access to those same database(s) by creating a Network Server object in the same application. 2) Currently, when the Network Server is shut down, it does NOT shut down the database(s) that it has been providing access to. This is important for users of the dual-access configuration, because they may well be continuing to access the database(s) through the embedded connection. It is a bit unfortunate that the same term (shutdown) is used in both cases. It would have better if one used start/stop for the network server and reserved shutdown for the database. I guess it is too late to do anything with that. 3) Unfortunately, in the simple Network Server case, this behavior is very non-intuitive, as most users would expect that when they shut down the Network Server in a clean fashion, that this would also shut down the database(s) in a clean fashion. 4) Unconditionally changing behavior (2) is worrisome, because it could affect existing applications (of either configuration). We should not take such a step lightly. I hope that there is general agreement about the above, so please indicate if I've got it wrong. In terms of what changes to make to the behavior of the Network Server, it seems that there are two basic proposals: - Don't add any new flags or arguments or commands; just make the Network Server shutdown do the right thing. Of course, this depends on whether we can agree on what the right thing is in all cases, and on whether the code has enough information to be able to do it. - Allow the end user to choose the shutdown behavior, by indicating whether they just want to shut down the Network Server, or whether they also want to shut down the database(s). My preference would be the former, because I think it would be less complex, easier to use, and simpler to document. I think that when the simple Network Server shuts down, it should shut down the databases it was providing access to, but when the Network Server has been started in a dual-access configuration in which there is also embedded access to the database(s) within the same application, the Network Server should *not* shut down the databases when it is shutting down. What if the existing method is changed to shut down the database if there is no other open connections to it? We would then probably have to add an option to force a shutdown even when there is open connections. So maybe this is just a variant of the second alternative above. At a minimum I think we should implement two shutdown modes (by adding one new NetworkServerControl flag). The current command does clean up including shutdown of all the databases (just like the parameter implies: ..NetworkServerControl -shutdown) the new mode just ends the Server (like is done now: ..NetworkServerControl -killServer ?). Using a term like 'kill' for the mode that does *NOT* shutdown down databases will indicate that is is an more abrupt ending. Issuing a warning and allowing an abort of the shutdown/kill when there are existing connections is a nicety but I think less important than having a clean (from a database standpoint) shutdown. I would argue that people that knowingly implement an embedded server architecture (i.e. dual-access configuration in which there is also embedded access to the database(s) within the same application) are savvy enough to understand the implications of dual-access and mange it in an appropriate manner.
[WWD] LAST CALL - for comments: CH 3 and 4 Revision 1.1 review
Please submit comments on Chapters 3 and 4 (rv 1.1) of Working With Derby by the end of business today. I will be preparing a PATCH for the commit of these chapters later today (along with some format updates of Chapters 1 and 2). Thanks Review background and links included below for your convenience. Original Message Subject:[WWD] CH 3 and 4 Revision 1.1 review Date: Sun, 16 Apr 2006 09:58:07 -0700 From: Stanley Bradbury [EMAIL PROTECTED] To: derby-user@db.apache.org I've attached the Review packet for the revision 1.1 of Ch 3 and 4 based on the feedback received from the community. To view the revisions download the file Review-WWD-Ch3-4rv1.1.zip ( http://issues.apache.org/jira/secure/attachment/12325379/Review-WWD-Ch3-4rv1.1.zip ). As requested, more detail and code examples were added to Ch 4, section 2: :The WwdEmbedded program (original draft ~750 word - rv1.1 ~1325 words). This section is not intended to teach JDBC and Java but rather describe the basic steps to access data in a Derby database using the embedded driver. Please let me know if this is adequate to describe the program to a beginning level programmer that is not familiar with JAVA or JDBC. If these drafts meet with general approval I hope to submit them for checkin late this week. === SNIP ==
Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]
David W. Van Couvering wrote: Thanks, Jean. In the meantime, those of you with project ideas can post them to the wiki site at http://wiki.apache.org/db-derby/CodingProjects David -- SNIP -- I have an idea but am not qualified to mentor the project other than providing input on the design. Should I list the idea anyway without a mentor? The idea (no surprise to anyone who knows me) is to create a light-weight GUI tool along the lines of the old Cloudview tool. Any code mentors / UI developers want to sign-up for that?
Quick Start link and Document link request [was: [web] Derby site reorganization (resend)]
Jean T. Anderson wrote: --- SNIP -- so, this is what the list would look like: Apache Derby Charter Quick Start Derby Wiki License FAQS any changes? -jean I have been looking at the new 'Quick Start' page on the Derby website and want to highlight this page in the final chapter of the Working With Derby document as the recommended 'Next Step' in finding out about Derby. One thing I would like to see added to the 'Basics' section of the page is a link to the online documents set ( http://db.apache.org/derby/manuals/index.html#docs_10.1) . Or possibly duplicate the document list, whatever seems best. The lack of a link to the documentation is the only online resource I can think of that is not neatly presented on this page. And something else I noticed 'Quick Start' is no longer a link in the sidebar of the HOME tab as shown above. I recall it was suggested that it be removed so this may be intentional - if not, please be advised it needs to be readded.
Re: [web/doc] Accessing DTDs locally vs. externally -- summary of Derby IRC chat
Jean T. Anderson wrote: There was a lengthy discussion on [EMAIL PROTECTED] that I'll summarize succinctly as: 1) Somebody requested a centralized location for Apache DTDs. 2) The request was turned down because of the load that resolving DTDs puts on Apache resources; DTDs should be accessed locally. Andrew and I chatted about this on IRC today because I've been confused about what kinds of operations this applies to and how to best address them. I have actually been vaguely aware of the issue since ApacheCon Europe when David Crossley (Forrest) mentioned that people using tools to edit forrest XML files should not be connecting to forrest.apache.org to resolve the DTDs. Since my XML editor is vi (and does no XML validation, for good or ill), I let this issue move to the background; however, I have been vaguely aware that every time I build the Derby web site it does in fact get the DTDs from forrest.apache.org. And after the discussion on the infrastructure list I realize that I do need to change this. So, to cut to the chase ... The Derby DITA doc builds are set up so that when you run ant to build the docs ( see http://db.apache.org/derby/manuals/dita.html for details), ant copies the DTDs from the DITA Toolkit into src/dtd in the Derby doc repo. The DITA files then include the appropriate DTD with a local, relative reference (../dtd/concept.dtd, ../dtd/reference.dtd, or ../dtd/task.dtd) I logged DERBY-1199 to fix the Derby web site source. Andrew and I discussed a strategy similar to the DITA one: simply commit the forrest DTDs to the Derby web site repo and put relative references in the XML files. I'm also looking into a link that Crossley posted to infra (http://forrest.apache.org/docs/catalog.html) to see if I can use an entity resolver for the build itself (as opposed to for editing tools), and if this can be done in a way that is super easy for other Derby web site builders. I'm still spinning up on the technical considerations and solutions. -jean Thanks Jean - I've been using the wrong reference in my DITA source files. I will update the references in the Dita Source files for the Working With Derby document. You've saved me some problems down the line. : )
Re: [Fwd: Re: [SHUTDOWN] Should I shutdown embedded data base ?]
Bryan Pendleton wrote: Moving this discussion to Derby-Dev because I want to ask a code-related question to Oystein: Have you had a chance to look at http://issues.apache.org/jira/browse/DERBY-51 Your comments seem to relate to a number of the issues raised in this bug. In particular, I am trying to understand the differences, *in the Network Server Environment*, between: - Shutting down a single database that is being served by the Network Server - Shutting down all the databases that the NS is serving, but leaving the NS itself up and running - Shutting down the Network Server itself, either - with, or - without shutting down the databases it is serving I've only looked at this a little bit, and have made myself thoroughly confused, so I was hoping that maybe you could shed some light in this area. thanks, bryan Original Message Subject: Re: [SHUTDOWN] Should I shutdown embedded data base ? From: Oystein Grovlen - Sun Norway [EMAIL PROTECTED] Note that a derby shutdown is just a shutdown of all databases you have opened. If you just have a single database, a single shut down is enough. Hi - There are two forms of shutdown and this is how it has been explained to me: 1) Used with a URL specifying a database name (jdbc:derby:myDB;shutdown=true) shuts down THE database specified by closing out all transactions, flushing the buffers to disk, checkpointing the transaction log and removing the db.lck file. NOTE: it leaves the Derby engine running within the JVM 2) Use without a database name (jdbc:derby:;shutdown=true) shuts down ALL database that were booted (doing all the above things for each) then shutsdown the Derby engine it self (I believe this means unloading the driver but Oystein will know for sure). I believe (Oystein or someone in the code can you confirm this) that when Network Server is shutdown it basically performs the form 2 (ALL) shutdown of Derby before exiting (if it does not then a bug needs to be filed). Unless there are specific reasons to do otherwise it is best NOT to shutdown datbases from the application but to let them be shutdown when the Server is shutdown. The reason is that there is no way to tell if someone else is also connected to the DB. If they are and you shutdown the DB the next query they make will fail cause the DB is gone. We need to play nicely in a shared environment. I think this addresses the situations you describe. I have noted that no database shutdown messages are writen to the log when the databases are shutdown along with Network Server and the db.lck file still exists afterwards so this process could use improvement.
Re: User code sharing? [ was: Re: Question?]
Jean T. Anderson wrote: Stanley Bradbury wrote: yeradis wrote: why other tools like sql server , postgres , oracle, enterprisedb, ... and last but not less Access are good? i think because they have built-in functions , simple funtions like julius mentioned of course what i mentioned is a very small feature but this small thinks are big aprecciated by the normal user ... SNIP === Is there a way that, as people implement such functions they could make the code available to others in the community who are also interested in the features? I guess I am thinking of a Derby user code sharing area. It seems a shame that others interested in the functions might need to write the same code and worse that users who do not program in JAVA cannot easily gain this functionality. We might be able to create a place on the Derby Wiki ( http://wiki.apache.org/db-derby/ ) for users to share code. One concern I have about putting it on the Wiki is users must contribute code under the ASL (http://www.apache.org/licenses/) , and there's no way to enforce that with the Wiki. For example, when you upload a file to a Jira issue it includes a step that allows granting license to the ASF. The Wiki doesn't have that feature. I'll ping community@apache.org to see what other apache projects are doing. -jean I thought that might be a problem. Thanks for checking to see if there is a precedent for this .
Re: derbytools.jar loading derbyclient.jar
Daniel John Debrunner wrote: Bryan Pendleton wrote: Here's a thought for a totally different approach to solving the original problem, which I will unfairly summarize as: Make it easier for brand new users to run Derby in trial situations without having to learn a lot about scripts and CLASSPATH settings. What if we shipped two configurations of the Derby classes: - the first configuration is the current one, with the Derby classes broken out into the separate jars. Each jar continues to be independent (no Class-Path manifest entries) - the new configuration is a single jar (derbyall.jar, say) which has all the classes from derby.jar, derbytools.jar, derbynet.jar and derbyclient.jar in a single jar file. Then, the new user tools and examples could just tell users to run things like java -jar derbyall.jar ij java -jar derbyall.jar NetworkServerControl start While the more advanced user, who wants to carefully load only the necessary classes, mix-and-match versions, etc., could continue to use the separate jar files as they did before. What do you think? Does an approach like this offer any value? That's a great idea, I would add one minor modification. Don't have the classes in derbyall.jar, just Class-path entries. Class-Path: derbynet.jar derbytools.jar derbyclient.jar Then it's (almost) the same functionality for almost zero overhead. The name may want to change as well, something that indicates it's really only for use as a command line tool. derbycmd.jar doesn't quite seem right, maybe others have better ideas. Dan. It just keeps getting better.+ 1
Re: derbytools.jar loading derbyclient.jar
Andrew McIntyre wrote: On 3/1/06, Kathey Marsden [EMAIL PROTECTED] wrote: How about *goderby.jar* Only 7 letters and documents itself as a vehicle to get you on your way. I like this. I also like the fact that it starts with g instead of d. It will stand out in the list of jars: one of these things is not like the others. If there are no objections, then I'll make the name goderby.jar. andrew Having all the jars start with 'derby' has the advantage of making them easy to search for and they will short together in an alphabetical listing like is produced by most directory listings. Having them sort together when listing out jarfiles in Server libdirectory or other jar repository environment is really nice. How about derbygo.jar ?
Re: default ij protocol (was Re: [WWD] review suspended)
Myrna van Lunteren wrote: On 2/24/06, *Andrew McIntyre* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/23/06, Satheesh Bandaram [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Andrew McIntyre wrote: java -jar lib/derbytools.jar ij IJ started without using the scripts seems to need a JDBC URL to connect. This may not be obvious to everyone and may seem odd to non-JDBC/java users. Should IJ (and other tools) be changed to assume jdbc:derby: protocol by default, if not provided? IJ is Derby's SQL processor, so it seems it should be ok to assume derby URL format, if none provided? == SNIP I think maybe this is a non-issue and something we should just do. It does change default behavior, but not in a way that should have any impact. Anyone else have a different opinion? andrew I wonder - could we leave ij alone, and in run.java add the check for protocol? That way, we leave all the capabilities of calling ij using the old scripts exactly as is, yet provide the ease of use of running java -jar derbytools.jar ij with a default protocol? Myrna If the change is just to create a default for ij.protocol then this should have no impact on existing applications. I like the idea so +1
Re: Derby - sysinfo call hangs
Mark Kurley wrote: -Original Message- From: Stanley Bradbury [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 12:00 PM To: derby-dev@db.apache.org Subject: Re: Derby - sysinfo call hangs Mark Kurley wrote: I was able to narrow it down some more. If I put this call in a loop it will eventually hang. org.apache.derby.drda.NetworkServerControl ping * SNIP * Here is more information when I run the NetworkServerControl ping command in a loop. The process eventually hangs. The CPU is quiet when the process hangs. 1) Derby.log Connection number: 2506. Connection number: 2507. Connection number: 2508. Connection number: 2509. 2) Output from runtimeinfo when process hangs. --- Cloudscape Network Server Runtime Information --- -- Session Information --- Session # :2511 - # Connection Threads : 3 # Active Sessions : 1 # Waiting Sessions : 0 Total Memory : 5110272 Free Memory : 2476784 3) Here is the sysinfo when it executes properly - Cloudscape Network Server Information Version: CSS1/10.0.2.0 Build: 30301 DRDA Product Id: CSS1 -- listing properties -- derby.drda.host=localhost derby.drda.portNumber=1527 derby.drda.startNetworkServer=false derby.drda.minThreads=1 derby.drda.traceAll=false derby.drda.logConnections=false derby.drda.maxThreads=0 derby.drda.timeSlice=0 -- Java Information -- Java Version:1.3.1 Java Vendor: IBM Corporation Java home: /usr/java131/jre Java classpath: /usr/local/derby/lib/derby.jar:/usr/local/derby/lib/derbynet.jar:/usr/lo cal/tomcat/webapps/spokeshopcs/WEB-INF/clas ses:/usr/local/tomcat/common/lib/servlet.jar::/usr/java131/jre/jre/lib/r t.jar:/usr/java131/jre:/usr/java131/jre/lib/dt.jar:/usr/java 131/jre/lib/tools.jar:/usr/local/tomcat/webapps/spokeshopcs/WEB-INF/lib/ *.jar://lib/tpcxpackages.jar OS name: AIX OS architecture: ppc OS version: 4.3 Java user name: tomcat Java user home: /home/tomcat Java user dir: /turns/local/tpcx/bin - Derby Information [/turns/local/derby/lib/derby.jar] 10.0.2.0 - (30301) [/turns/local/derby/lib/derbynet.jar] 10.0.2.0 - (30301) [/turns/local/tomcat/webapps/spokeshopcs/WEB-INF/classes] 10.0.2.0 - (30301) -- - Locale Information - -- Notice: This transmission is for the sole use of the intended recipient(s) and may contain information that is confidential and/or privileged. If you are not the intended recipient, please delete this transmission and any attachments and notify the sender by return email immediately. Any unauthorized review, use, disclosure or distribution is prohibited. Hi Mark - The noteworthy result is that the Network Server is not hanging - it resonds to the 'runtimeinfo' request and I expect would respond to 'sysinfo' and accept other connections as well. So the problem appears to be with the client. Are you running the client in the same JVM as the server? I found issue 300 regarding hangs in that configuration: http://issues.apache.org/jira/browse/DERBY-300 (this problem only reproduces on 1.3.1 jvms). I searched for other known issues with NetworkServerControl on AIX but found no clear 'smoking gun' so I can only speculate. I note that you are using the initial release of Derby (10.0.2.0) and a 1.3.1 JVM. Please try your test with the most recent release of Derby and a 1.4.1 (or higher) JVM. If upgrading the JVM is not an option please be sure you are using the most recent JVM service release. There are a number of fixes that have been applied to the IBM 1.3.1 JVM that are important for Derby to work reliably. If the problem still occurs then there may be a problem with the NetworkServerControl program and it would be great if you filed a JIRA entry on this and attached your test case. Please let me know what you find.
Re: Derby - sysinfo call hangs
Mark Kurley wrote: I was able to narrow it down some more. If I put this call in a loop it will eventually hang. org.apache.derby.drda.NetworkServerControl ping Does anyone have any ideas why this would sometimes hang? Thanks -mark -Original Message- From: Mark Kurley [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 11:06 AM To: derby-dev@db.apache.org Subject: RE: Derby - sysinfo call hangs We are running this on AIX. When the process hangs I try to send kill -QUIT pid to the process but it just hangs. I get an entry in the file /tmp/javacore_locations. For example it added the entry /tmp/javacore45520.1139323327.txt But this core dump file does not exist. The process continues to hang until I send kill -9 pid. So for some reason it seems like the process never receives the kill -QUIT. Any suggestions on how I can figure out when the call to the sysinfo script hangs sometimes? Thanks -mark -Original Message- From: Bryan Pendleton [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 5:35 PM To: derby-dev@db.apache.org Subject: Re: Derby - sysinfo call hangs I have noticed that sometimes when I call the sysinfo script the process hangs. You didn't mention what platform you are running, but you should be able to get a Java Stack Trace showing all the threads in the sysinfo process, and what they are waiting on: - On Windows, use Control-Break: Hold down the Control key and press the Break key. - On Unix systems, send kill -QUIT to the process which is running sysinfo, from some other window on that machine. Then, capture the output from the Java Stack Trace, and send it along. That will provide more information about where in the sysinfo script it is hanging. thanks, bryan Notice: This transmission is for the sole use of the intended recipient(s) and may contain information that is confidential and/or privileged. If you are not the intended recipient, please delete this transmission and any attachments and notify the sender by return email immediately. Any unauthorized review, use, disclosure or distribution is prohibited. Notice: This transmission is for the sole use of the intended recipient(s) and may contain information that is confidential and/or privileged. If you are not the intended recipient, please delete this transmission and any attachments and notify the sender by return email immediately. Any unauthorized review, use, disclosure or distribution is prohibited. It would be very helpful to know what messages are in the derby.log file and to get the information provided by 'NetworkServerControl sysinfo' (when it does execute properly). Once it hangs please try issuing 'NetworkServerControl runtimeinfo' - if this returns there may be useful information - please post that as well. Lastly, when a hang happens is the CPU quiet or very active?
Re: Derby - sysinfo call hangs
Mark Kurley wrote: Hi, I have noticed that sometimes when I call the sysinfo script the process hangs. There are no entries in the log files. I even when as far as writing a shell script that calls the sysinfo in a loop. It fails on different iterations each time. Has anyone else experienced this problem? I am not sure how to debug this problem. Please pass along any information. Thanks -mark *Notice:* This transmission is for the sole use of the intended recipient(s) and may contain information that is confidential and/or privileged. If you are not the intended recipient, please delete this transmission and any attachments and notify the sender by return email immediately. Any unauthorized review, use, disclosure or distribution is prohibited. I've see the NetworkServer sysinfo (the one in %DERBY_INSTALL%\frameworks\NetworkServer\bin) take a long to return when NetworkServer has not been started. Always thought it had something to do with the setting of network timeouts but don't know for sure. Is this the script you are using? Not sure why the loop would fail on different iterations but perhaps connections have been exhausted? Of course if you are using the script in embedded then .. Never Mind HTH
Re: Keeping derby.properties and the database files in different directories
Afkham Azeez wrote: Hi Folks, I have my derby.properties file in $MY_PROJECT/conf directory. This is the directory pointed to by the derby.system.home System property. But no my database is getting created under $MY_PROJECT/conf e.g. as $MY_PROJECT/conf/DATABASE. I need my database to be created as $MY_PROJECT/DATABASE. Is there a property I can specify in the derby.properties file which will specify the physical location of the Database? -- Thanks in Advance Afkham Azeez You have a couple of options. 1) If the URL is being specified in a program you can expand $MY_PROJECT and use it to construct a fullpath database URL (e.g. DriverManager.getConnection(jdbc:derby:/var/myProjDir/theDB) 2) Otherwise you need to set the properties someway other than using a derby.properties file. Set derby.system.home to the location where you want your databases created and set the properties as JVM arguments (e.g. java -Dproperty=value) in a way similar to how you are setting derby.system.home. the properties. If you are using a Server there is often a .properties file that the server loads when it starts. HTH
Re: Derby Driver
Sean McCully wrote: Apologies should I continue the discussion here or move it? Yes when I execute the derby jar it works, and actually I was able to get the driver to load by merely replacing the String name with a String constant but on subsequents loads it failed. Also this may be due to the computer I was using which experienced a crashed afterwards. I will check tommorrow and move this discussion to the derby-user mailing list. Thanks!! */ SNIP ... /* On 11/17/05, *Sean McCully* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello I probably have a rather simple question, when I execute the following line Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance(); it throws the following exception java.lang.ClassNotFoundException : org.apache.derby.jdbc.EmbeddedDriver derby.jar is included in my Classpath, what is the problem? Hi Sean - Are you using and IDE or executing in a server environment? In these cases you need to be sure that derby.jar is in the classpath of the Server / IDE. Hope it's something as easy as this.
