Re: Is enq: TX - row lock contention a wait or syscall

Hi Stefan!

This applicable only to the systems which do have SVR4 IPC and are using the traditional Oracle process architecture. I would also add that this is a strong argument in favor of the threaded architecture which doesn't utilize SVR4 IPC nearly as much as the traditional architecture. The reason is precisely the prevalence of the system calls in the traditional architecture. As you are aware, a system service call is actually a system trap, performing "switch mode to kernel" operation which requires saving all the user mode registers on the stack and an interrupt to change the processor modes. Now, interrupt processing is expensive and is to be avoided if possible. On the other hand, your analysis is not applicable to threaded systems, like Windows, so it cannot be considered a general case.

For some reasons, DBA people are conservative and very reluctant to switch to the threaded architecture. I have tested it and find it very good indeed. I've had problems with the "datapatch" utility when the database is running in the threaded mode, and have resolved them by setting TWO_TASK variable. I've recently become lazy with blogging. Thanks for reminding me. Will fix that soon.

Regards

On 1/21/20 2:16 AM, Stefan Koehler wrote:
> Hello Kunwar,
> as all others already replied: Yes, the wait event "enq: TX - row lock contention" instruments a wait on syscall semtimedop() in the background.
>
> On my website you can find a simple example how the locking / synchronization works:http://www.soocs.de/public/research/190513_semaphore_sync.txt
>
> Best Regards
> Stefan Koehler

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

--
http://www.freelists.org/webpage/oracle-l