Summary

This chapter covered locking, transactions, and concurrency in PeopleSoft. As discussed in the first part of this chapter, when a PeopleSoft application does require a database lock, it usually does so by creating a row-level lock by updating a table that has only a single row.

Database transactions generated by PIA activity should usually be short-lived because they never wait for user response. In that respect, they can be thought of as very small batch processes. Thus, any locks that they hold are held only for a short time. It is unusual to find PIA save-time processing locked on other PIA save-time processing.

Care must be taken when making customizations—especially in SaveEdit, FieldChange, FieldEdit, and SavePreChg PeopleCode, which fire at save-time—that these changes do not introduce locking or significantly extend the length of the transaction because of poorly performing SQL. A single, isolated transaction may be affected by “only” a fraction of a second, which may escape unnoticed in unit testing. However, in a high-concurrency situation, the holding of a row lock for an extended period can easily translate into many seconds or even minutes of performance degradation to the business function (I’ve seen it), ultimately to the point at which the system becomes effectively unusable.