Hi Petter, [ CC-ing the Pharo Users list ]
P3Client is not built/designed to be used by multiple processes concurrently. Each database connection is represented by an instance of P3Client and holds some state both at the client as well as at the server side. Typically, in a multi user server application, each connection should have its own P3Client / psql connection. For example, in Seaside, a custom WASession subclass gives each session/user its own p3 connection/client. Is that what you are doing ? If not, you could wrap your db accessing code so that mutual exclusion is provided. For example, you can have a look at AbstractCache #beThreadSafe and #critical: That will then serialise requests and possibly block one onto the other. HTH, Sven PS: another thing to take care of if closing your sql connections when the session is no longer needed. PS: Zinc HTTP does also provide a session mechanism (ZnServerSession[Manager]) but these work with cookies and typically won't help with a REST access pattern. > On 9 Feb 2020, at 14:21, Petter Egesund <petter.eges...@gmail.com> wrote: > > Hi Sven > > We are using Pharo as our backend in a project and we have run into a problem > with P3. > > The problem seems to be connected to compiled sql statements and concurrency. > > We keep getting this error: Bindcomplete message expected > > Problem seems to be easy to reproduce: > > 1) Compile any sql statement > 2) Use this statement in a query twice (!) in a teapot endpoint > > The run some concurrent queries, like "curl http://localhost:8080/endpoint & > curl http://localhost:8080/endpoint.." (add several curls after here). > > One could also use ex. siege > (https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html) for easy > reproducing. > > If we chain the curls after each other, like "curl > http://localhost:8080/endpoint && > https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html && > https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html.." it seems to > work fine, so doing the request sequentially seem to work fine. > > My conclusion is that this must be connected to how teapot handles > concurrency in companion with the compiled statements? > > Any clues on this one? We are on Pharo 8.0 with latest version of P3, PG 9.x) > > Best regards > > Petter Egesund (I wrote the heysql-package based on P3)