mORMot Open Source

I wrote with a context in my mind and I might haven't express myself in a good way.
I know that "The threads are part of the thread pool, so they are by definition allocated at startup, until the process exits." and there is nothing wrong with. What I'm asking is if there is a (default) way to a server kill those threads automatically, if they are inactive.

It can help. If there are no new requests, threads will die and for the next new request they will be created again, using a new connection.

"allow me to replace binaries without forcing a shutdown" need a better explanation (my mistake, sorry):
I want to implement a "A/B service" which means that, if I need to replace the instance-A, I will first publish an instance-B, change the URI and port (that remains in a database) for all new requests point to the new service instance. Then, when all requests finished in instance-A, I'm able to remove the binary, replacing with the same version in B — for the next version I can do the opposite, starting with instance-B.

If threads are not killed automatically, I need to check the server using another approach only to know if something stay in process.
Just as an example, using IIS + FastCGI + fpWeb, I can setup IIS to kill my threads using the approach that I've explained above. But I'm not using IIS or Apache... just mORMot.

Have you understood now?

Just to mention: TADOConnection has a KeepConnection property, which means that. And it works.
But I need my services more stronger than that. For example, if the network has down/broke, KeepConnection is not enough and an exception will occur.

So, when I got this exception was because it was running in a develop database, which is renew every day, dropping all connections of course.

The DBMS will kill connection in a period of time on idle, but the thread won't know about it; then the client will get an exception.

@macfly
If I understood correct the concept of your pool, you could still get an exception by inactivity. I mean, if no client sent a request, you can't be able to remove any other inactivity connection... but only by a timer (do you use?).

Anyway, I still thinking that would be nice and easier if the server finished threads by end of a (configurable) period.

At least in my case, I don't care if next request will be the first that will create all threads again, as all were gone eventually. Does mORMot can do that?

There is Spring4D but I've never used and I don't think it is relevant, due we already have mORMot.

Actually, I'm not using any connection pool yet. That's why I'm using threadvar.

@Javierus
Yes, I create the MainDataModule and open the connection.
No, this DataModule just have one ADOConnection and 2~3 ADOQuery for others thing that I'm not using on this service.
The business rules were coded (mostly) in classes, no DataModules. But all SQL/Scripts that are used by these classes are in ADOQuery among many DataModules, just for not write SQL as strings and use theirs master/detail features for reports, etc.

But the whole DataModule is a threadvar.
On OnCreate event there is just calls to conn.Close; fill user and passwd; conn.Open.
In my mind it should be thread-safe... Didn't raise exception anymore, it fixed itself

Actually, it's working now using BeginCurrentThread/EndCurrentThread.
I've changed the code to call SynOleDb.CoInit/CoUninit instead from ActiveX unit—maybe because it's thread safe.
Also, I've instantiate the ADOConnection, inside a MainDataModule, using a TSynLocker.

I have just one question: the MainDataModule is a threadvar. Is it really needed using a TSynLocker on BeginCurrentThread/EndCurrentThread?

I totally agree with you about Delphi, but I was talking about Object Pascal in general.
I use Delphi 7 because of a legacy product too. New projects I use FPC/Lazarus.

@macfly

You're saying that "format settings" should be coded as a constant? Besides, it should be used always when call "TSynStr.Format()"?
Put the format in a constant is not a good idea, if your system should work with other format... but this is another history.
Look, what I'm saying is this:

var
  fs: TFormatSettings;
  du: TSynDateTimeUtils;
  s1, s2, s3: string;
begin
  fs... // initialized with some format
  s1 := du.ToString(Now, fs); // I can do this OR...
  du.FormatSettings := fs; // ...I can set just one time
  s2 := du.ToString(Now); // ...and it will use du.FormatSettings here (overloaded method)...
  s3 := du.ToString(Now); // ...and here
end;

@Junior/RO

There is no `class var` in old Delphi versions to keep some fields that could be shared among functions in an object/record structure.

I prefer not using classes for simple routines that a function can do the job. However, I dont think procedures / functions should be in interface section for users of any framework—we have OOP—because they may not have a good semantic; we can get name collisions; functions can be overriden easily just adding an unit after another (see Trim), etc. Pascal has the perfect structure to do it, which is called plain "old" object or, nowadays, "record with methods".

I'll have simultaneous users and that is why I need multi thread.
Today we have a monolithic ERP using a single connect, but the main goal is to share the business rules on it on a website (written in Java).

The code has a TMainDataModule, which has a "singleton" MainDataModule variable. The ADOConnection is there. All other Forms and DataModule point to it.
Then, I thought in another possibility: What about using the MainDataModule as a threadvar?
- I don't need to implement my own pool
- the ERP code remains exactly it is (mostly)
- I "just" need to initialize/finalize the instance on each thread

What do you think?

Maybe a framework/lib shouldn't export any procedure or function, only types. These prevent any compilation issues, as you can't use a type—which has the same name for another—in arguments that doen't fit in.

We already have objects and classes. Why should I export for users—in interface section—functions if I can code an plain-object with a group of functions, which has the same context, on it?

TrimU() could have any context... but what about this:

TSynString = object
public
  function Trim(const aValue: RawUTF8): RawUTF8;
  function Copy(...
  // etc...
end;

TSynDateTime = object
public
  function Iso8601ToDateTime(const S: RawByteString): TDateTime; overload;
  function Iso8601ToDateTimePUTF8Char(P: PUTF8Char; L: integer = 0): TDateTime;
  {$ifdef HASINLINE}inline;{$endif}
  procedure Iso8601ToDateTimePUTF8CharVar(P: PUTF8Char; L: integer; var result: TDateTime);
  // etc...
end;

Using "Syn" as a prefix is another discussion... it was just an example.

But if these types have or not a prefix, I can still "rename a lot of functions", if I want to, instead each function:

type
  TMormotStringHelper = mormot.core.base.TSynString;

So, Arnaud, you asked which DB I'm using and I've answered above...

I can't use OleDB or any other connection type (in this first refactoring) because those services uses a lot of TADOQuery, which some has master/detail, events, and so on. I believe it will be simpler keeping ADOConnection, but I'm sure that I need to implements a connection pool for them, otherwise the new services/daemon won't have a good performance.

Do you have any more tips or advices about my thoughts on that architecture?

Bounded context for new projects from scratch, you're right.
But I'm used to maintain old projects, which mostly never used mORMot, and it could be very hard to do a refactoring to use mORMot when those conflicts pop up. But yes, there are several solutions.

I think Pascal should have a syntax that could end this discussion about using or not prefixes:

uses
  mormot.core.base as mcore;

function Clean(const aValue: RawUTF8): RawUTF8;
begin
  result := mcore.Trim(aValue);
end;

Even better it would be, if we can use the same alias for more than one unit:

uses
  mormot.core.base as mormot;
  mormot.core.datetime as mormot;

function MyTrim(const aValue: RawUTF8): RawUTF8;
begin
  result := mormot.Trim(aValue);
end;

function MyIso8601ToDateTime(const aValue: RawByteString): TDateTime;
begin
  result := mormot.Iso8601ToDateTime(aValue);
end;

So, if you got any conflict, you just need to use an alias (a little one) as prefix!

edwinsn,
Some frameworks/libs use the same prefix for all types (e.g. Indy, TMS, JEDI, DevExpress, etc) but, even though it could minimize eventual collision names, it's not perfect as anyone can use the same prefix as other already has used.
It could be very verbose either. Imagine typing TMormotTextWritter or TMormotOrm (!!).
Simple names are better to read, however it could have colision... difficult decison.
However, in my opinion, if the framework/lib uses an abstract prefix (e.g. Id, Jv, dx, etc), it must be in all types. That is consistency.

I think I can use OleDB after the first refactor, due the deadline...
If I can code a pool for the same connection component, everything on ERP will continue working without MUCH changes, as the ERP will use 1 connection at all as always be.

I never used mORMot OleDB, so I don't know if I gonna have some issues (e.g. all queries will run smoothly?) and other things that I didn't think yet.
I'm using MSSQL 2008.

I will see the slides now...

I've never configureted the IIS + http.sys, so I would like a little more help, if you don't mind.

Well, I wrote the basics... now I have more information:
- First services will be used on local network, which means (for me) that I do not need to use IIS for them, but you see some advantage using it?
- The ERP code has a "classic" datamodule with a ADOConnection component, which is used all over the code. Should I initialize that connection in a specific place that is thread safe?

About automatic updates, I didn't work on it, but you remembered well. I will take a look on the sources.

What you mean? On Github page says "Targets Delphi 5 up to Delphi 10.3 Rio (and latest version of FPC)..." so, it suppose to work on FPC, but you say LCL... I got confused here.

I've never used SynPdf so, sorry if my question sounds silly.

It's not my API, otherwise it wouldn't have this issue

"Roger that."

I've coded the client that consume the API and it's written using records/objects all over the place—I can't change this now.

Thanks for try to help. If the API continues changing, I will continue investigating what has changed.

1. I didn't mean that these functions need to work with the same type and/or same private attributes. I meant that it might be good to group similar functions into an "auxiliary" object, which contains everything about a subject. For example, in another topic, you told us about the `TrimControlChars ()` function, which we didn't know about. Whether this function exists within an object, e.g. "TSynStringHelper", it could be easier to find it instead search all functions inside an unit. Besides, the code completion will tell us about all related (string stuff) in this "help object".

2. Understood, thanks.