Smartservice ORM issue

Home Forums kbmMW Smartservice ORM issue

This topic contains 4 replies, has 2 voices, and was last updated by  kimbomadsen 7 months, 1 week ago.

  • Author
    Posts
  • #53458

    mrluigi2017
    Participant

    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

  • #53459

    kimbomadsen
    Keymaster

    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

  • #53460

    mrluigi2017
    Participant

    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!

  • #53461

    mrluigi2017
    Participant

    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

     

     

    • #53472

      kimbomadsen
      Keymaster

      Hi,

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

      best regards

      Kim/C4D

You must be logged in to reply to this topic.