by sbutler » Fri Jan 24, 2020 4:18 pm
We've always done parallel deployments when upgrading. Make sure you aren't using Servoy sequences, and you should generally be ok. There is no data broadcasting between servers as others have mentioned, but usually this isn't a showstopper. It only becomes a problem in a scenario like this: User A on new system views a record. User B on old System updates the same record. User A on new system views the record again, now User A maybe viewing cached/outdated data.
So, to get around this I usually try to group the client beta testers together if possible. Lets say its an order management system, take all the people that do phone orders and put them on the new system and put the people that do email orders on the old, or whatever make sense for your situation. Essentially keep users that are more likely to access the same records grouped together. If you have a multi-tenant system, then just do the 1 whole tenant.
To get around the data broadcasting you have a few options...
- Sledge Hammer: use flushAllClientsCache(serverName, tableName) on a scheduled batch processor. This will have a large performance impact and is generally avoided.
- Normal Hammer: use notifyDataChange(serverName, tableName, pksDataset, action) on a scheduled batch processor, by using raw SQL to search for modified data by timestamp (assuming you have a modified date in each table).
- Scalpel: Build a system to handle data broadcasting. Either your own pub/sub implementation using something like RabbitMQ to trigger notifications between servers, or by building web service endpoints in Servoy, and hit them in table events to communicate between servers. Servoy added native RabbitMQ in Servoy 8, but I don't think it was ever officially added to 7. Just be careful you don't get yourself in an infinite broadcasting cycle.