[
https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831429#comment-13831429
]
Knut Anders Hatlen commented on DERBY-4917:
-------------------------------------------
I don't think r1492111 changed the behaviour (intentionally, anyway) so the
problem is most likely still there.
DirFile.getExclusiveFileLock() now has this comment (in code copied from
DirFile4):
{code}
/*
** There can be a scenario where there is some other JVM that is
before jkdk1.4
** had booted the system and jdk1.4 trying to boot it, in this case we
will get the
** Exclusive Lock even though some other JVM has already booted the
database. But
** the lock is not a reliable one , so we should still throw the
warning.
** The Way we identify this case is if "dbex.lck" file size is differen
** for pre jdk1.4 jvms and jdk1.4 or above.
** Zero size "dbex.lck" file is created by a jvm i.e before jdk1.4 and
** File created by jdk1.4 or above writes EXCLUSIVE_FILE_LOCK value
into the file.
** If we are unable to acquire the lock means other JVM that
** currently booted the system is also JDK1.4 or above;
** In this case we could confidently throw a exception instead of
** of a warning.
**/
{code}
> 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 was sent by Atlassian JIRA
(v6.1#6144)
