Dear all,
I apologize for my late reply.
I realized that the current implementation could not imitate the oracle's
precompiler.
The attached example can be accepted by both precompilers, but building the c
file made by ecpg fails.
For handling this source, we have to refactor some sources
Dear Matsumura-san, Horiguchi-san,
We should check the specfication of Pro*c before coding
because this follows its feature.
I'll test some cases and send you a simple report.
Best Regards,
Hayato Kuroda
Fujitsu LIMITED
Horiguchi-san, Kuroda-san
> Horiguchi-san wrote:
> > A namespace of declared statement is not connection independent.
> > Therefore, we must manage the namespce in global and consider about race
> > condition.
>
> Right, and but thread independent.
I was wrong. I understand that DECLARE
Oops.
At Fri, 15 Mar 2019 15:33:50 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190315.153350.226491548.horiguchi.kyot...@lab.ntt.co.jp>
> > // If ecpglib didn't reject the above, ecpglib cannot judge
> > // which connection the followings should be executed on.
> > exec
At Fri, 15 Mar 2019 05:27:01 +, "Matsumura, Ryo"
wrote in
<03040DFF97E6E54E88D3BFEE5F5480F737AC3F24@G01JPEXMBYT04>
> Hi Horiguchi-san, Kuroda-san
>
> Horiguchi-san, thank you for your comment.
>
> I have a question.
> A bug of StatementCache is occurred in previous versions.
> Should a
Hi Horiguchi-san, Kuroda-san
Horiguchi-san, thank you for your comment.
I have a question.
A bug of StatementCache is occurred in previous versions.
Should a patch be separated?
> Horiguchi-san wrote:
> It seems like a local cache of server-side data, which is similar
> to catcache on server
At Thu, 14 Mar 2019 09:49:11 +, "Matsumura, Ryo"
wrote in
<03040DFF97E6E54E88D3BFEE5F5480F737AC3AD8@G01JPEXMBYT04>
> Horiguchi-san
>
> Thank you for your comment.
>
> > A connection cannot be concurrently used by multiple threads so
> > the programmer must guard connections using mutex
Horiguchi-san
Thank you for your comment.
> A connection cannot be concurrently used by multiple threads so
> the programmer must guard connections using mutex [1] or
> friends. If it is done by a single mutex (I suppose it is
> common.), there's no race condition also on the prepared
>
Hello.
At Thu, 14 Mar 2019 07:17:08 +, "Matsumura, Ryo"
wrote in
<03040DFF97E6E54E88D3BFEE5F5480F737AC390D@G01JPEXMBYT04>
> Hi
>
> I'm afraid that PREPARE of ecpglib is not thread safe.
> The following global variables are modified without any locking system.
> Is it unnecessary worry?
>
Hi
I'm afraid that PREPARE of ecpglib is not thread safe.
The following global variables are modified without any locking system.
Is it unnecessary worry?
[interfaces/ecpg/ecpglib/prepare.c]
static int nextStmtID = 1;
static stmtCacheEntry *stmtCacheEntries = NULL;
static struct
10 matches
Mail list logo
