DBMS_lock scalability and conflicts with MTS

I am working with a client server application which utilizes a locking mechanism to lock business objects which correspond to collections of rows from multiple tables. The application is being upgraded and the number of users increased. The current application's locking mechanism is based on a table and will probably not handle the increased load. We are thinking of using dbms_lock to manage the locks. Has anyone got any experience of using dbms_lock with a large number of sessions. I am familiar with dbms_lock but need to understand it's scalability potential.

The system is on HPUX it will have up to 1200 concurrently connected users many of whom may hold up to 3 locks. If anyone can answer any of the following questions I would be grateful

Can the dbms_lock package handle this kind of load. The package header states that the implementation only supports up to a few hundred locks per session. I need a thousand sessions each with a few locks.

Has anyone had any problems with the dbms_lock_allocated table which contains the lock name to handle mapping. How large can this table get before it becomes a performance issue. What are the uses around setting a non default value for expiration_seconds in dbms_lock.allocate_unique

The dbms_lock package documentation briefly states that there are issues with using dbms_lock and Multi Threaded Server (MTS). It states that when a lock is held by a server process that process cannot service any other users until the lock is released. Has anyone got any experience of this.

Any other advice would be appreciated Received on Wed Sep 02 1998 - 13:15:11 CDT