Re: [Exist-open] inconsistent db-state after neverending query

[Wolfgang M. <wol...@ex...>]

Hi Matej,

I found one issue and fixed it:

http://exist.svn.sourceforge.net/exist/?rev=16411&view=rev

eXist did not write a checkpoint if a long running thread had to be
killed during shutdown, thus causing a recovery run every time. I have
now changed the transaction manager to write a checkpoint if all write
transactions returned properly. It should thus be safer to kill a
blocking db.

This could help in your case, though I suspect there must be something
else because above issue does not fully explain the failure I have
observed on one of my servers last week. There might be a problem with
transactions not being properly aborted. I will add some code to force
an abort on a transaction if it has been completely inactive for 10
minutes or so. This will at least help to locate the issue.

Wolfgang


2012/5/17 tech.vronk <te...@vr...>:
> Hi  Wolfgang,
>
> thank you for the  information.
>
> Is there anything I can do meanwhile preemptively,
> to prevent this from happening again,
> like restarting the database
> or running the consistency checks more often?
>
> Or meanwhile just backup often enough,
> check the queries twice before running and pray?
>
> thanks again.
>
> matej
>
>
> Am 17.05.2012 10:52, schrieb Wolfgang Meier:
>
>> Hi,
>>
>>> I have experienced quite problematic behaviour of the exist-db lately.
>>>
>>> I have the 2.0-tech-preview version running.
>>>
>>> After an (obviously) inefficient query that ran for ever,
>>> on next start
>>> the 'exist' instance" could not be found.
>>
>> I had a similar issue the other day: probably a deadlocked thread
>> which prevented eXist from creating a checkpoint for several days.
>> Upon restart I had a huge transaction log, which fortunately was ok
>> and the data could be restored by recovery.
>>
>> Normally eXist should create a checkpoint when the last write
>> transaction completes, but it seems we have a problem here in 2.x.,
>> resulting in a risky recovery run whenever you have to kill the db.
>> I'm looking into this today.
>>
>> Wolfgang
>>
>>
>