We have a performance problem with the Mac clients (PPC + Intel) in the network. On lauching the smart clients, the performance is good for 2 or 3 hours. Then the speed for changing forms, starting transactions and so on is going down to freeze the Client. On waiting 5 to 10 minutes it’s working again for the next 30 minutes…
The MS SQL-Sever is on a Win XP machine, the Firewalls on the Client PC’s are off. A Servoy Server logfile is attached for a better help.
I’m also not getting the performance I would expect on the Mac (10.4.x, Java 1.5), but we don’t have that many freezes.
I can see from your log that you end up with deadlocks maybe caused by the transactions.
Not sure this applies in your case: A long time ago I was coding with transactions in Servoy, possible in version 2.0, and found that starting a transaction in Servoy would lock up an entire table. This meant that I could only wrap transactions around code which would execute in one go. So, you can’t use transactions when a user edits a form, since it may take a while – but you can have one around a few lines of code when you save.
thank you for your fast replay! Your answer is very interessting for me, because I liked to use transactions (start, rollback, commit) for creating new records and editing. It is an easy way to have always an option to cancel the last changes. It will be a lot of work to change my methodes, but if that will be a better solution and performance I do.
Ok, I will try that out. An other thing is to handle saved existing records. Edited records should set back (rollback) to the previous values with ‘cancel’ when perhaps inserted wrong values. Editing records in my opinion have to be saved by confirming the action and not on entering data, or?
Yet another point maybe is, that in practice customers hold transactions started for a longer time (more than 5 or 10 minutes) before they commit with the ‘save’ button. Could this cause the performance problem?
tgs:
Yet another point maybe is, that in practice customers hold transactions started for a longer time (more than 5 or 10 minutes) before they commit with the ‘save’ button. Could this cause the performance problem?
tgs:
Ok, I will try that out. An other thing is to handle saved existing records. Edited records should set back (rollback) to the previous values with ‘cancel’ when perhaps inserted wrong values. Editing records in my opinion have to be saved by confirming the action and not on entering data, or?
This behaviour is what you often see with web forms, as a side-effect of the limitations of HTTP. You can get around it with Ajax.
In Servoy, I use field validation and the on_save table event to reject bad data, so I don’t have any distinct ‘edit’ mode with a possibility to cancel. Keep it simple.
Now, you you want to go down a more complex route, you could deal with edit the following way:
Assume each user only logged on once and editing one record in the table at any time.
Each user has an id.
Table filter only shows records with positive id.
Create a record for each user with id = -userid.
These records will normally not show.
When user wants to edit, you copy the record you want to edit to the ‘user specific record’ and show using your ‘edit’ form. On save you copy back, on ‘cancel’ you don’t. You just need to find a way not to lose the original pk of the record…
In a new workaround I replaced the transaction functions:
databaseManager.startTransaction()
databaseManager.rollbackTransaction()
databaseManager.commitTransaction()
databaseManager.hasTransaction()
and that is working well. I have only to do a few changes in my code. But deleting a record can’t be canceled with a rollback.
Thank you for your suggestions.
Because it is in praxi quite to extremely lavishly! Sounds easy but for real applications to handle all possible cases and allow for a rollback is extremely lavishly - my opinion only.
Best regards, Robert
ROCLASI:
Why not using the servoy ‘transactions’ (i.e. disable autosave and save manually) ?
That will work exactly like a webform does.
Not everything is perfect. In this case Thomas can’t use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.
So depending on your use Servoy transactions might be the best and even painless solution.
For all other situations where using Servoy transactions don’t suffice I am sure you all know your way to the support system for bug reports and feature requests.
ROCLASI:
In this case Thomas can’t use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.
Is this a general problem with MS-SQL? Or “only” in combination with Servoy?
ROCLASI:
So depending on your use Servoy transactions might be the best and even painless solution.
For all other situations where using Servoy transactions don’t suffice I am sure you all know your way to the support system for bug reports and feature requests.
ROCLASI:
In this case Thomas can’t use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.
Is this a general problem with MS-SQL? Or “only” in combination with Servoy?
Assuming that database transactions are managed, as the name implies, on the database I would say yes. I also did some quick googling and found other instances of table locks in MS-SQL using other (MS) technologies as well.
You would think a modern (O)RDBMS would support row-level locking instead of table locking when using transactions (I know PostgreSQL and Oracle do).
Then again using database transactions and keeping them open for 5+ minutes could also be seen as misuse of transactions. I don’t think they were ever designed for that.
I think a combination of in-memory ‘transactions’ and the final write to the database using database transactions might be the best approach.
tgs:
But deleting a record can’t be canceled with a rollback.
Thank you for your suggestions.
Instead of actually deleting you can set a ‘deleted’ flag on the record, and exclude ‘deleted’ records when searching. You will need some way of showing ‘deleted’ records so they can be un-deleted by clearing the flag.
It is a little bit more tricky to change the functionality as I posted a couple of days before.
Find + search doesn’t work on AutoSave(false), in a related tabpanel only the last changes will rollback and a few more things.
Transactions would be a cool and professional solution…, if it doesn’t locks the backend MS SQL database tables…
tgs:
We have a performance problem with the Mac clients (PPC + Intel) in the network. On lauching the smart clients, the performance is good for 2 or 3 hours. Then the speed for changing forms, starting transactions and so on is going down to freeze the Client. On waiting 5 to 10 minutes it’s working again for the next 30 minutes…
Please have a look at the suggestions over here: viewtopic.php?f=5&t=11380
It seems to me you are running low on client memory
