<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Laura,</p>
<p>(I'm coming at this as someone familiar with SQLite but not
GRASS)</p>
<p>As far as I can tell, the journal_mode PRAGMA is non-persistent.
So if you set it within SQLite at the command line, then that
setting is only going to remain set during that connection. GRASS
uses its own connection so will use the default (DELETE) unless
otherwise set.</p>
<p>The exception is WAL - Write Ahead Log. This setting persists.
Take a look at <a class="moz-txt-link-freetext" href="https://sqlite.org/wal.html">https://sqlite.org/wal.html</a> to see if it's suited
to your use-case. Then if you set it, it should remain set when
GRASS uses the db.</p>
<p>As far as I can tell doing a quick search of the GRASS code using
github, the journal_mode is only set once, via the temporal python
library to MEMORY -
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/grass/search?utf8=%E2%9C%93&q=journal_mode&type=">https://github.com/OSGeo/grass/search?utf8=%E2%9C%93&q=journal_mode&type=</a></p>
<p>The other way to work around this non-persistent journal_mode is:
"Note also that the journal_mode cannot be changed while a
transaction is active." - so keep a connection-with-transaction
open via not-GRASS while GRASS is doing its thing.</p>
<p>Cheers,</p>
<p>Jonathan<br>
</p>
<br>
<div class="moz-cite-prefix">On 16/05/2019 09:28, Laura Poggio
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKmfgFPnPN9RoKBqx8i6JgissFuqjD3hRShf2KA5R9SKwdWPFg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Dear all,
<div>thanks for the answers and apologies if my question at
the beginning was not so clear.</div>
<div>SQLITE can support multiple readers and only one writer.
But it is not the main problem. </div>
<div>The issue here is the creation of the journal file. Each
time a GRASS session that modified the sqlite.db file is
closed, the journal file is created. This can take quite
some time and during this time the database is locked. This
behaviour is expected.</div>
<div>I can turn off the creation of the journal file (being
aware of the potential risks) using sqlite options and thus
reducing the time the database is locked. However these
options do not apply when the file is modified by GRASS.</div>
<div>Is it possible to turn off the creation of the journal
file when a GRASS session is involved?</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>Laura</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 16 May 2019 at
00:07, Nikos Alexandris <<a
href="mailto:nik@nikosalexandris.net"
moz-do-not-send="true">nik@nikosalexandris.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">* Markus Metz <<a
href="mailto:markus.metz.giswork@gmail.com"
target="_blank" moz-do-not-send="true">markus.metz.giswork@gmail.com</a>>
[2019-05-15 22:55:13 +0200]:<br>
<br>
>On Tue, May 14, 2019 at 11:12 AM Panagiotis Mavrogiorgos
<<a href="mailto:pmav99@gmail.com" target="_blank"
moz-do-not-send="true">pmav99@gmail.com</a>><br>
>wrote:<br>
>><br>
>> Hi Laura,<br>
>><br>
>> This thread seems to be related:<br>
><a
href="http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html</a><br>
>> I also had a somewhat similar problem that was
related to the VACUUM<br>
>command issued when closing a GRASS session (new session
started before the<br>
>VACUUM of the previous session was finished)<br>
>> If I understand this correctly, you are not
supposed to concurrently use<br>
>the same sqlite database.<br>
><br>
>Yes, this is a limitation of sqlite, and the
GRASS-internal sqlite driver<br>
>has been adapted accordingly as much as possible.<br>
<br>
Nevertheless, concurrent reading is allowed. Reading the
discussion so<br>
far, one may think that no concurrent use is possible at
all.<br>
<br>
See also <a href="https://sqlite.org/whentouse.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://sqlite.org/whentouse.html</a>
:<br>
<br>
"SQLite supports an unlimited number of simultaneous
readers, but it<br>
will only allow one writer at any instant in time."<br>
<br>
And in <a href="https://sqlite.org/lockingv3.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://sqlite.org/lockingv3.html</a>
see 'SHARED'.<br>
Also, <a href="https://stackoverflow.com/a/4060838/1172302"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://stackoverflow.com/a/4060838/1172302</a>.<br>
<br>
Nikos<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank"
moz-do-not-send="true">grass-user@lists.osgeo.org</a><br>
<a
href="https://lists.osgeo.org/mailman/listinfo/grass-user"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/grass-user</a></blockquote>
</div>
</div>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
grass-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a></pre>
</blockquote>
<br>
</body>
</html>