Re: IC freezes

--===============1965683995==
Content-Type: multipart/alternative; boundary="000000000000b8572405708ffeca"

--000000000000b8572405708ffeca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No. GDBM databases are tied to GDBM files, period.

ALL locale tables are loaded into memory when IC starts, no matter what
underlying DB structure they use. This doesn't mean that, if you update
them, that the rules for databases are changed.

There is also a MEMORY db type, but that has no advantage for Locale,
because, again, all locale tables are loaded into memory even if they are
SQL or GDBM.

On Mon, Jul 9, 2018 at 6:29 AM, Ren=C3=A9 <[email protected]> wrote:

>
> On 09.07.2018 01:12, Mike Heins wrote:
>
>> As I said initially, I am sure this is a file locking issue. If you
>> update GDBM files, you are going to get locking problems while it is
>> happening. The locks stay on until the process ends, and this should hap=
pen
>> for any Interchange and Perl.
>>
>> You will continue to have some problems as long as you are updating GDBM
>> databases from the running process. Move the DB to SQL and the problems
>> should disappear.
>>
>
> Hi,
>
> Isn't the idea with the gdbm-tables that they get loaded into memory when
> IC is reloaded, and speeds up the translation-process?
>
> If the same can be fixed with an sql-database, then this would be really
> great!
>
> Ren=C3=A9
>
> _______________________________________________
> interchange-users mailing list
> [email protected]
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>



--=20
Just because something is obviously happening doesn't mean something
obvious is happening. --Larry Wall

--000000000000b8572405708ffeca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>No. GDBM databases are tied to GDBM files, period.<br=
></div><div><br></div><div>ALL locale tables are loaded into memory when IC=
 starts, no matter what underlying DB structure they use. This doesn&#39;t =
mean that, if you update them, that the rules for databases are changed.</d=
iv><div><br></div><div>There is also a MEMORY db type, but that has no adva=
ntage for Locale, because, again, all locale tables are loaded into memory =
even if they are SQL or GDBM.<br></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Mon, Jul 9, 2018 at 6:29 AM, Ren=C3=A9 <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><br>
On 09.07.2018 01:12, Mike Heins wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As I said initially, I am sure this is a file locking issue. If you update =
GDBM files, you are going to get locking problems while it is happening. Th=
e locks stay on until the process ends, and this should happen for any Inte=
rchange and Perl.<br>
<br>
You will continue to have some problems as long as you are updating GDBM da=
tabases from the running process. Move the DB to SQL and the problems shoul=
d disappear.<br>
</blockquote>
<br>
Hi,<br>
<br>
Isn&#39;t the idea with the gdbm-tables that they get loaded into memory wh=
en IC is reloaded, and speeds up the translation-process?<br>
<br>
If the same can be fixed with an sql-database, then this would be really gr=
eat!<br>
<br>
Ren=C3=A9<br>
<br>
______________________________<wbr>_________________<br>
interchange-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">inter=
[email protected]<wbr>rg</a><br>
<a href=3D"http://www.icdevgroup.org/mailman/listinfo/interchange-users" re=
l=3D"noreferrer" target=3D"_blank">http://www.icdevgroup.org/mail<wbr>man/l=
istinfo/interchange-users</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Just becau=
se something is obviously happening doesn&#39;t mean something<br>obvious i=
s happening. --Larry Wall<br></div></div></div>
</div>

--000000000000b8572405708ffeca--


--===============1965683995==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
interchange-users mailing list
[email protected]
http://www.icdevgroup.org/mailman/listinfo/interchange-users

--===============1965683995==--