<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">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">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">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">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">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">https://sqlite.org/lockingv3.html</a> see 'SHARED'.<br>
Also, <a href="https://stackoverflow.com/a/4060838/1172302" rel="noreferrer" target="_blank">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">grass-user@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-user</a></blockquote></div></div>