You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2010/11/25 00:41:14 UTC
[jira] Created: (DERBY-4917) zero byte dbex.lck file can cause dual
boot warning saying Severe and non-recoverable corruption can result and
may have already occurred.
zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
-------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-4917
URL: https://issues.apache.org/jira/browse/DERBY-4917
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.2.1
Environment: z/OS
E205{S000EKA}> java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
20100215 (SR
11 FP1 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
20100127a
(JIT enabled)
J9VM - 20100122_52103_bHdSMr
JIT - 20091016_1845ifx1_r8
GC - 20091026_AA)
JCL - 20100215
Derby 10.2.2.1 - (815839)
Reporter: Kathey Marsden
User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
ij> connnect 'jdbc:derby:wombat';
IJ ERROR: Unable to establish connection
ij> connect 'jdbc:derby:wombat';
WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
boot the database <snip dbname > even though Derby (instance c0
13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
erby should boot a database at a time. Severe and non-recoverable corruption can
result and may have already occurred.
The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
mv dbex.lck dbex.lck.orig
touch dbex.lck
java org.apache.derby.tools.ij
ij version 10.2
ij> connnect 'jdbc:derby:wombat';
IJ ERROR: Unable to establish connection
ij> connect 'jdbc:derby:wombat';
WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
erby should boot a database at a time. Severe and non-recoverable corruption can
result and may have already occurred.
I see the same warning with 10.7.
Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4917) zero byte dbex.lck file can cause dual
boot warning saying Severe and non-recoverable corruption can result and
may have already occurred.
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-4917:
----------------------------------
Urgency: Normal
Labels: derby_triage10_8 (was: )
triaged for 10.8.
Discussed with kathy who reported this issue and has worked with only site that has seen this issue. Her suggestions:
There are really two issues here. 1) Why might the lock be created at zero length. This one we don't understand so can't do anything about it.
2) If there exists a zero length file for whatever reason (e.g.) was created with old JDK, we always produce this warning and don't do proper dual boot checking.
So I think we should fix the second part of this issue, by removing DirFile and just having DirFile4 now that JDK 1.3.1 is no longer supported.
> zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4917
> URL: https://issues.apache.org/jira/browse/DERBY-4917
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.2.1
> Environment: z/OS
> E205{S000EKA}> java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
> 20100215 (SR
> 11 FP1 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
> 20100127a
> (JIT enabled)
> J9VM - 20100122_52103_bHdSMr
> JIT - 20091016_1845ifx1_r8
> GC - 20091026_AA)
> JCL - 20100215
> Derby 10.2.2.1 - (815839)
> Reporter: Kathey Marsden
> Labels: derby_triage10_8
> Attachments: ExLockFile.java, SimpleConnect.java, derby-4917_10_2_debug_diff.txt
>
>
> User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database <snip dbname > even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
> 1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
> 2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
> I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
> mv dbex.lck dbex.lck.orig
> touch dbex.lck
> java org.apache.derby.tools.ij
> ij version 10.2
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> I see the same warning with 10.7.
> Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4917) zero byte dbex.lck file can cause dual
boot warning saying Severe and non-recoverable corruption can result and
may have already occurred.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4917:
----------------------------------
Attachment: ExLockFile.java
SimpleConnect.java
Here are a couple of small programs for diagnosing the problem that I asked the user to run.,
The first program SimpleConnect, makes a connection to the database and checks the size of the lock file created.
It should be run as
java SimpleConnect <path to database>
The System.out output should be captured and returned along with the derby.log.
On my system the output is:
$ java SimpleConnect /u/kmarsd/repro/lockwarn/wombat
dbex.lck exists and is length:4
Rename dbex.lck to dbex.lck.sav with f.renameTo
Connection successfully madeorg.apache.derby.impl.jdbc.EmbedConnection30@1023687
94 (XID = 40), (SESSIONID = 0), (DATABASE = /u/kmarsd/repro/lockwarn/wombat), (D
RDAID = null)
length of dbex.lck file:4
I expect on the user machine the dbex.lck file will be of length 0 which will narrow the problem outside of the applicatoin to just Derby. If it shows length 4 then something in the application environment must be influencing the locking.
Assuming the length shows 0 with SimpleConnect, the second program has just the lock file creation and locking code:
run like
java ExLockFile <path to db>
The output on my system is:
java ExLockFile /u/kmarsd/repro/lockwarn/wombat
/u/kmarsd/repro/lockwarn/wombat exists. Attempt exclusive lock
create file succeded. validExclusiveLock=true
1)lockFileOpen = new RandomAccessFile((File) this, "rw")
1) Complete lockFileOpen =java.io.RandomAccessFile@44ba44ba
2) lockFileChannel = lockFileOpen.getChannel()
2) Complete lockFileChannel = sun.nio.ch.FileChannelImpl@51ac51ac
3) dbLock = LockFileChannel.tryLock()
3) Complete dbLock = sun.nio.ch.FileLockImpl[0:9223372036854775807 exclusive val
id]
lockFileOpen.writeInt(EXCLUSIVE_FILE_LOCK)
writeIntSuccessful
lockFileChannel.force(true)
lockChannel.force(true) successful
status = EXCLUSIVE_FILE_LOCK
Lock status is:1-EXCLUSIVE_FILE_LOCK
f.length() = 4
I am thinking maybe at the site we will see an IOException or some sort of other clue.
> zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4917
> URL: https://issues.apache.org/jira/browse/DERBY-4917
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.2.1
> Environment: z/OS
> E205{S000EKA}> java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
> 20100215 (SR
> 11 FP1 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
> 20100127a
> (JIT enabled)
> J9VM - 20100122_52103_bHdSMr
> JIT - 20091016_1845ifx1_r8
> GC - 20091026_AA)
> JCL - 20100215
> Derby 10.2.2.1 - (815839)
> Reporter: Kathey Marsden
> Attachments: ExLockFile.java, SimpleConnect.java
>
>
> User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database <snip dbname > even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
> 1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
> 2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
> I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
> mv dbex.lck dbex.lck.orig
> touch dbex.lck
> java org.apache.derby.tools.ij
> ij version 10.2
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> I see the same warning with 10.7.
> Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4917) zero byte dbex.lck file can cause
dual boot warning saying Severe and non-recoverable corruption can result
and may have already occurred.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981818#action_12981818 ]
Kathey Marsden commented on DERBY-4917:
---------------------------------------
At the site using a user privileged to run command line programs, the test programs ran and created the lock file with 4 bytes as expected. They are not able to run the programs with the problematic id with the scheduled task so I am going to work to make a debug 10.2 build to try to help diagnose the problem.
> zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4917
> URL: https://issues.apache.org/jira/browse/DERBY-4917
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.2.1
> Environment: z/OS
> E205{S000EKA}> java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
> 20100215 (SR
> 11 FP1 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
> 20100127a
> (JIT enabled)
> J9VM - 20100122_52103_bHdSMr
> JIT - 20091016_1845ifx1_r8
> GC - 20091026_AA)
> JCL - 20100215
> Derby 10.2.2.1 - (815839)
> Reporter: Kathey Marsden
> Attachments: ExLockFile.java, SimpleConnect.java
>
>
> User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database <snip dbname > even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
> 1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
> 2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
> I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
> mv dbex.lck dbex.lck.orig
> touch dbex.lck
> java org.apache.derby.tools.ij
> ij version 10.2
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> I see the same warning with 10.7.
> Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Updated] (DERBY-4917) zero byte dbex.lck file can cause
dual boot warning saying Severe and non-recoverable corruption can result
and may have already occurred.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4917:
----------------------------------
Issue & fix info: Workaround attached (was: High Value Fix,Workaround attached)
Unchecking HVF. I think the cases at this point where there is a residual zero byte db.lck from JDK 1.3 are rare. It would be great to get rid of DirFile as a refactoring and code simplification effort but as a HVF bug this issue probably no longer qualifies.
> zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4917
> URL: https://issues.apache.org/jira/browse/DERBY-4917
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.2.1
> Environment: z/OS
> E205{S000EKA}> java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
> 20100215 (SR
> 11 FP1 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
> 20100127a
> (JIT enabled)
> J9VM - 20100122_52103_bHdSMr
> JIT - 20091016_1845ifx1_r8
> GC - 20091026_AA)
> JCL - 20100215
> Derby 10.2.2.1 - (815839)
> Reporter: Kathey Marsden
> Labels: derby_triage10_8
> Attachments: derby-4917_10_2_debug_diff.txt, ExLockFile.java, SimpleConnect.java
>
>
> User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database <snip dbname > even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
> 1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
> 2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
> I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
> mv dbex.lck dbex.lck.orig
> touch dbex.lck
> java org.apache.derby.tools.ij
> ij version 10.2
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> I see the same warning with 10.7.
> Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4917) zero byte dbex.lck file can cause dual
boot warning saying Severe and non-recoverable corruption can result and
may have already occurred.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4917:
----------------------------------
Attachment: derby-4917_10_2_debug_diff.txt
This is the debug patch I sent to the user to help diagnose the problem. It prints a javacore on boot and adds lots of debug printout in DirFile4.getExclusiveLock and also throws an assertion if we for some reason get into DirFile.getExclusiveLock() instead of Dirfile4. It is not for commit!
> zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4917
> URL: https://issues.apache.org/jira/browse/DERBY-4917
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.2.1
> Environment: z/OS
> E205{S000EKA}> java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
> 20100215 (SR
> 11 FP1 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
> 20100127a
> (JIT enabled)
> J9VM - 20100122_52103_bHdSMr
> JIT - 20091016_1845ifx1_r8
> GC - 20091026_AA)
> JCL - 20100215
> Derby 10.2.2.1 - (815839)
> Reporter: Kathey Marsden
> Attachments: derby-4917_10_2_debug_diff.txt, ExLockFile.java, SimpleConnect.java
>
>
> User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1 on z/OS.
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database <snip dbname > even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> The dbex.lck file is zero length. The code seems to indicate in DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if the product is booted with less than JDK 1.4 and Derby should show the warning under these circumstances, but investigation shows that even if the dbex,lck file is removed it is recreated with zero length using JDK 1.5. So there seem to be two issues.
> 1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this machine with JDK 1.5 SR11 FP1.
> 2) We have this logic pertaining to JDK 1.3.1 in the product that probably can be removed and perhaps masks a real exclusive locking problem that perhaps should issue an Error rather than a warning if the file cannot be created with 4 bytes as expected.
> I can mimic the Warning on my system with a manufactured zero length dbex.lck file e.g.
> mv dbex.lck dbex.lck.orig
> touch dbex.lck
> java org.apache.derby.tools.ij
> ij version 10.2
> ij> connnect 'jdbc:derby:wombat';
> IJ ERROR: Unable to establish connection
> ij> connect 'jdbc:derby:wombat';
> WARNING: Derby (instance c013800d-012c-8027-19b4-000000037b18) is attempting to
> boot the database /u/kmarsd/repro/lockwarn/wombat even though Derby (instance c0
> 13800d-012c-74ae-07c3-0000000af3f0) may still be active. Only one instance of D
> erby should boot a database at a time. Severe and non-recoverable corruption can
> result and may have already occurred.
> I see the same warning with 10.7.
> Possible workaround for eliminating the warning is to do a clean shutdown of the derby database before exiting the jvm which will remove the lck files, but it is hard to know if the user is getting actual dual boot protection under these circumstances.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.