[
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
