Servoy Forum

We are considering splitting up or server instances into 2 in order to reduce what appears to be some strain on the server, which causes slow downs and restarts during working hours. Data propagation is not an issue as the users would be split by tenants.

Is there any issue in having both servoy instances pointing towards the same repository database? I am assuming that this DB is only really used when downloading the solutions and therefore if it is on the same private cloud, wouldn't be a great issue if two VMs with a servoy instance pointed at it?

It would just appear to be a little easier to maintain the solutions, or should the theory be that if the load is enough to warrant two servoy instances we should have two repositories to match?

David

Hi David,

what about the customer data, is that 1 database too?

I think this should work, a few things to think about:
1) number of database connections: as there are 2 application servers, the sum of connections which are allowed on both instances must be allowed on the database server as well
2) in case you have 1 database with customer data (and you mentioned this already): make sure the same tenants use the same instance.
3) in case of multiple databases (different ones connected to the 2 application servers): be aware while updating your solution on 1 instance, the other instance doesn't know about this update and therefor will not create new tables/columns/i18n/etc. in your 2nd customer database
4) after updating one instance, make sure to restart the 2nd instance as this one isn't aware of the update, but also database changes (in case of 1 customer database). This could be a problem when you've clients connected. Anyway 'Live' updates on 1 of your solution is not supported anymore.
5) batch processors: If you are using batch processors, make sure each application server is only touching data of the tenants which are on that application server.

This is what I can quickly think about.
Anyone else missing stuff?

A better solution would be to use clustering (Terracotta). One thing to keep in mind is that I was told this is currently running only under Java 6.
Using clustering, you don't have to worry about all the stuff above.

Well one thing that might be an issue are Servoy sequences.
Servoy keeps track of these in the servoy repository. Now I don't know when 2 server instances use the same repo will play nice in this regard.
If Servoy holds the next sequence in memory then you get into trouble really quick.
If Servoy gets the next sequence from the repository database then you are prone to a race condition (depending on how Servoy does the select (for update)).

In any case it will be better to be using database managed sequences/identities when you want to go this route.

Another thing would be data broadcasting, for this you need the clustering (Terracota) solution.

Do not connect two servers to one repository! Use Servoy Cluster for that. It is specially build for that