db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Read+write deadlock in default Derby
Date Fri, 30 Sep 2005 18:15:41 GMT
I am not sure where you got that impression.  The default isolation
level for derby is read committed.  Derby's implementaiton of read
committed gets short term read locks to guarantee that the data being
read is committed data.

If you don't want read locks then you may want to look at running
your isolation level at read uncommitted.

Lars Clausen wrote:
> Hi!
> 
> I was under the impression that by default Derby does not take locks
> when reading, so deadlocks should only occur when two updates collide. 
> However, I had the exception below this morning:
> 
> Sep 29, 2005 10:38:48 AM
> dk.netarkivet.harvestscheduler.HarvestScheduler$1 run
> SEVERE: Exception while scheduling new jobs
> dk.netarkivet.exceptions.IOFailure: SQL Error while reading harvest definition 14
>         at
> dk.netarkivet.harvestdefinition.HarvestDefinitionDBDAO.read(HarvestDefinitionDBDAO.java:349)
>         at
> dk.netarkivet.harvestdefinition.HarvestDefinitionDBDAO$1.filter(HarvestDefinitionDBDAO.java:505)
>         at
> dk.netarkivet.harvestdefinition.HarvestDefinitionDBDAO$1.filter(HarvestDefinitionDBDAO.java:504)
>         at dk.netarkivet.utils.FilterIterator.hasNext(FilterIterator.java:70)
>         at
> dk.netarkivet.harvestdefinition.HarvestDefinitionDAO.generateJobs(HarvestDefinitionDAO.java:180)
>         at
> dk.netarkivet.harvestscheduler.HarvestScheduler.scheduleJobs(HarvestScheduler.java:200)
>         at
> dk.netarkivet.harvestscheduler.HarvestScheduler.access$100(HarvestScheduler.java:58)
>         at
> dk.netarkivet.harvestscheduler.HarvestScheduler$1.run(HarvestScheduler.java:136)
>         at java.util.TimerThread.mainLoop(Timer.java:512)
>         at java.util.TimerThread.run(Timer.java:462)
> Caused by: SQL Exception: A lock could not be obtained due to a deadlock, cycle
> of locks and waiters is:
> Lock : ROW, DOMAINS, (346,20)
>   Waiting XID : {3556682, S} , APP, SELECT domains.name, configurations.name
> FROM domains, configurations, harvest_configs WHERE harvest_id = ?  AND
> configurations.config_id = harvest_configs.config_id  AND
> configurations.domain_id = domains.domain_id
>   Granted XID : {3556738, X}
> Lock : ROW, CONFIGURATIONS, (410,270)
>   Waiting XID : {3556738, X} , APP, UPDATE configurations SET comments = ?,
> template_id = ( SELECT template_id FROM ordertemplates WHERE name = ? ),
> maxobjects = ?, maxrate = ?, overridelimits = ?WHERE name = ? AND domain_id = ?
>   Granted XID : {3556682, S}
> . The selected victim is XID : 3556682.
>         at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
>         at
> dk.netarkivet.harvestdefinition.HarvestDefinitionDBDAO.read(HarvestDefinitionDBDAO.java:330)
>         ... 9 more
> 
> The first lock shown (SELECT domains.name, ...) is inside an entirely
> read-only function, so it is strange that it should deadlock.  We are
> using default settings for Derby.  Is there any way this could actually
> be caused by that read, or should I really go around looking for an
> unfinished transaction somewhere before that select?
> 
> Thanks,
> -Lars
> ________________________________________________________________________
> 
> 

Mime
View raw message