When baan generates update session by default the script commits after 50 transactions. What are the benefits of this approach?

Suppose I have a table where 30000 records are there. I change one field in all the records and do a single commit. What difference in performance this approach would have compared to baan standard update session where it commits after every few transactions?

Regards,
Srinivas

I've heart once that when too many records are updated within a single transaction at some point Baan can't handle all these changes internally and will temporarily write the changes to a swapfile on disk. This is time consuming. Besides that, Baan will lock all changed records in this situaton (so delayed locks are changed into hard locks) which means that other users can get locking errors when accessing same data.

Youp

It is not only topic of performance.
In worst case commit will never be done, because such a lot of records cannot be buffered.
Normally commit will be used with db.retry.point. If commit fails baan will go back do retry point and update records again and try to commit.
Commit can fail without fatal errors in database so you would not notity.

Greetings Andy

One benefit of a single commit that I can think of is if you are updating a group of records based on similar criteria. If one of these updates fail then the whole transaction will roll back and no records will be updated. If you do a commit after each update there is no way to roll back the transaction.

However with your example of 30000 records you will need to make sure that you have sufficient system resources available to cater for the huge transaction that you will be creating.