DB2 Files being locked
Vivian Yang
file via JDBC/Connection Pool.
After I closed the connection, I find the db file is still being locked
by the QZDASOINIT job. It will prevent the file being cleared. The lock
is released if I restart the application server. Is there anyother way
to release the lock by programm level?
Thanks.
Vivian Yang
Frances Stewart
rollback was not performed. How are you using the JDBC withing WebSphere
(e.g. from a servlet, from a BMP enterpsie bean, from a CMP enterprise
bean)? Also are you using the connection pooling support from WebSphere
(i.e. Datasource object)?
Another possibilty is that the AS/400 containing the DB file is not up to
date of PTFs. Also, you should make sure that you are using a recent version
of the Toolbox (we recommend modification level 2 or 3 - with latest PTFs;
or the JT/Open open source version). Modification level 1 is not
recommended.
gles...@my-deja.com
>Frances Stewart <fran...@us.ibm.com> wrote:
Hi,
I, too, just encountered this error today. My enviroment is a bit
different than the original poster's, but the error is the same, as is
the mystery.
My config:
-NT Server 4.0 sp6
-WS Adv v. 3.0.2.2
-DB2 on AS/400
-NT connected through Client Access ODBC driver, using Sun ODBC/JDBC
driver over a VPN. I'll move to the proper AS/400 jdbc driver once I
deploy there.
> How are you using
> the JDBC withing WebSphere
> (e.g. from a servlet, from a BMP enterpsie
> bean, from a CMP enterprise
> bean)?
using servlets.
> Also are you using the connection pooling
>support from WebSphere
> (i.e. Datasource object)?
using WebSphere DataSources to get connections.
(com.ibm.db2.jdbc.app.stdext.javax.sql.DataSource)
> Another possibilty is that the AS/400
>containing the DB file is not up to
> date of PTFs.
I'm not the AS/400 admin, but as of four months ago it was up to date
on all ptf's.
>Also, you should make sure that you are using a
>recent version
> of the Toolbox (we recommend modification level
>2 or 3 - with latest PTFs;
not using the Toolbox jdbc drivers yet.
Anyway, the end result is that a file/table of mine is in a deadlock
state, one process with it open as read-only, the other with it open
for update. The job number itself is 018274/QUSER/QZDASOINIT, and
restarting the stuff on our side does not work. So, right now the lock
is still active, and I don't know why.
any help would be greatly appreciated,
George
Sent via Deja.com http://www.deja.com/
Before you buy.
George Lessmann
Hi,
I, too, just encountered this error the other day. My enviroment is a bit
Art Smet
WRKOBJLCK for example even if the job is really done with the locked object.
This aids performance by avoiding re-locking/re-unlocking when an SQL job
repeatedly performs operations on a collection/table. Such locks are designed to
be immediately unlocked if a lock conflict is detected from another job.
I have seen times a deadlock or lock timeout because of some kind of breakdown
in this pseudo-lock design. To make matters difficult, you can't tell by
looking whether such a held LOCK is a pseudo-lock or a true LOCK that is held
because a commit has not yet been issued.
A couple things to try that may help understanding the LOCKing problem better:
1. A pseudo-lock will disappear if you enter interactive SQL and issue the
following:
LOCK TABLE <collection>/<table> IN EXCLUSIVE MODE
- if this is successful, then any previously held locks have been released
because they were pseudo-locks. This may be the programmatic way of forcing the
release of such locks, which may solve your problem. If so, then I think this
may indicate an IBM bug in the "open for update" or "clear" path.
- if unsuccessful, then there exists a real lock on the conflicted on object,
move on to the next step:
2. Locate the job that owns the conflicted on LOCK.
- WRKJOB
- option 16 display commitment control status
- option 5 against the commitment def'n
- f6 display resource status
- option 1 against Record level and Object level
- - (may have to scroll) do you see any pending commits in the right-hand column
for any file?