I’m experiencing unexpected major technical difficulties in producing a functional demo of a Servoy solution.
I’m ready to go to market. Last step is to put up a decent demo, one which anyone can access to at any time, no special procedures, just download the Servoy Client applet and log on. Go immediately to a set of sample records. Navigate around, create new records, alter existing ones, experiment. And when the prospect is gone the sample records revert to their original condition.
In addition, the system should be able to accommodate several demo users simultaneously. For marketing reasons it just won’t do to ask a prospect to come back later. So, support for several concurrent users is important.
It’s quite possible with Servoy for multiple computers to log in with the same user name and password concurrently. I’ve done it, logged on with my beta tester’s user name and password while he also is also up and running.
In other words one Servoy security user name and user id can be seen as having two different IP addresses simultaneously.
This fact will create difficulties for the database if I start a transaction as soon as someone logs on as “demo”. From experience I’ve discovered this vulnerability can lock out all users from logging on.
I’m using Sybase ASA. Someone has suggested:
Transactions also lock data so if you use them in multi user systems always use them with caution, if you use them a lot use a database with multiversion capabilities like Oracle or Postgres.
For demos transactions are not the way to go.
An alternatives would be to rebuild the sample records nightly. Not a good solution for two reasons. The system could be in the midst of rebuilding when someone in Asia is logged on (middle of the day). And most prospects would see whatever mess was left behind by previous users that day. Less than ideal on both counts.
I’ve also received this recommendation:
You can consider using the sql plugin to perform delete and insert statements upon log-off or use a stored procedure for this.
I’m not sure, but I suspect this scenario is just as vulnerable to being triggered when someone else is logged onto the demo.
I’m not keen on switching databases at this late stage and Sybase ASA has been just fine thus far. Nevertheless I’m willing to entertain the idea.
Another Servoy user who uses Postgres said this:
I don’t know if PostgreSQL is gonna solve your problem. Even though PostgreSQL has multiversion capabilities I still have sometimes a lock like you describe.
My guess is that this has to do with the Servoy framework. Since your client connects to the database through servoy then Servoy is the one that owns the database connection (and thus the session). Most of the time that is only 5 to 10 connections at the same time (a preference you can set in the Servoy database connections).
I think you have to ask Servoy how they handle transactions in Servoy. Like will it reserve a connection for the duration of that transaction so that the database can keep them seperate?
I’ve gone onto one of Sybase’s public forums to get advice from that direction. They offer two suggestions.
- Create temporary tables when the prospect logs on as “demo”, kill the temporary tables when they leave.
The concept (and management) of temporary tables is new and strange to me and I’m not sure whether existing forms would present data from temporary tables or manage relationships properly.
- Create several identical sets of demo records. When the user logs on, direct them to an unused set. Start a transaction when they log on, roll it back when they quit.
This would work if I first checked to see which of my demo sets was currently unused and changed their assigned Servoy security id to the one associated with that set. I could do that, but I see no available Servoy function which will do that. In Servoy it would appear only the Servoy Client user can set the Servoy security user id.
To summarize, I need a way for several prospects to log on to a demo concurrently. Each demo tester doesn’t interfer with the actions of other users. And the demo records remain unchanged when the tester quits.
I seem to be blocked in each direction I turn. I need a workable scenario.
Kind regards,