Multiple instances of a RO Server, using each different configuration. Things to take into account?

Hello,

In one of my installations there are 3 different “business objects” to be run. Those instances will access different databases, and the clients will connect either to one or to other. But they should be running at the same time, and on the same machine.

The server/clients are using a different set of ports to connect to each other.

Is there any things to take into consideration? The servers are made on C++Builder XE5. The channels supported are SuperTCP, TCP, and NamedPipes (although so far we have been only using the SuperTCP one).

I ask this because it seems like there are some concurrency/race condition, most notably when closing down the apps. If I try to close the two servers (closing the main window, this aren’t running as a service yet) then on multiple occasions the app has frozen and I have to kill it with TaskManager.

Thanks

pls read this faq

Hello Evgeny,

Thanks for the link. I’ve read it, and will try some of the possible workarounds.

Just a question: the simple object, I believe, doesn’t have the session manager property like the datamodule-inherited ones has? I couldn’t find it.

I would certainly prefer to use the simple object route, instead of having to mess with the server component’s creation.

You are right - TRORemotable doesn’t have SessionManager.
If you need, you can create TRORemotable descendant and add SessionManager support like TRORemoteDataModule has…

Ok. Can you register this (adding the SessionManager to the TRORemotable) to your issue tracking? I’m guessing this is as usable here as it is on a DataModule, and more if using DataModules causes this kind of issues.

I will create my own descendant from TRORemotable to implement there that property for the time being.

Thanks.

Sorry, but TRORemotable should be simple enough

To clarify, the idea is that TRORemotable stays a very simple class w/o overhead, where you’d do these kind of things yourself, while TRORemoteDataModule is the version with all the bells and whistles. I recommend adding your own TRORemotable descendant that adds there SessionManager logic, and base your services on that, if you cannot use TRORemoteDataModule.

Does that sounds reasonable?