Smartservice ORM issue

[mrluigi2017]

Hi,

I have written a smart service with REST support and everything works fine as long as there is one request at a time. When I start loadtesting with JMeter with multiple “clients” at a time I get some vague errors. This seems to happen only when I want to insert a new record (didn’t try updates yet, reading works fine) . Sometimes it’s a access violation, sometimes it just doesn’t work. When I check my Postgres 10 Logfiles I see various message/warnings:

LOG: unexpected EOF on client connection with an open transaction
WARNING: there is no transaction in progress
WARNING: there is already a transaction in progress

Because I wanted to exclude some causes I wrote some test applications with Unidac components in a thread, kbmmwUnidac in a thread and ORM + kbmmwUnidac. They all worked well except that I had to create an ORM instance in each thread for the last test to make it work.

I tried to use the kbmmw log, but when I did this the problem was gone. So my log option are limited.

My questions:

1) What dac did you use to test postgres?
2) Could you confirm that your postgres test could serve multiple concurrent requests?
3) Any suggestions what the problem might be or how I can figure it out?

Thanks in advance!

Luigi

[kimbomadsen]

Hi,

1) I have not specifically stability tested PostgreSQL since it all depends on DAC, settings and more. What have been tested is the SQL rewriting since that much depends on each supported database. The ORM is being used in several customer projects, where it is stressed to different level of degrees, but mainly connected to SQLite and MSSQL. Since the ORM depends on the traditional connection pool system, I would say the issues you see would appear also using the connection pool and most likely also using the DAC directly with similar load and same settings.
2) See above. The connection pool system has been tried and tested for 15 years in various very high load systems, so that certainly can handle multiple connections completely stable.
3) My guess is that its related to DAC transaction isolation settings.

best regards
Kim/C4D

[mrluigi2017]

I did some testing with kbmmwFiredac yesterday and it works fine. I think you are right that it has to do with transaction settings. I don’t want to blame kbmmw 🙂 but could it be that in the unidac adapter InternalOpenConnection method some connection properties are not set? Am I right that if a property isn’t set here the default value is used?

Thanks in advance!

[mrluigi2017]

I have added the one line of code and it works 🙂

Not sure if this is a general solution or just for kbmMWUnidac and PostgreSQL. I think it is a general solution because I believe that transactions should be only controlled from within the kbmmw framework.

I have added this line of code in the InternalOpenConnection method.

FDatabase.AutoCommit := False; // Is true by default in UniConnection

 

 

[kimbomadsen]

Hi,

Thank you for your feedback and solution. Ill add it to next release.

best regards

Kim/C4D

[Author]

Posts