[
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.embedconnectio...@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.randomaccessf...@44ba44ba
2) lockFileChannel = lockFileOpen.getChannel()
2) Complete lockFileChannel = sun.nio.ch.filechanneli...@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.
