Issue 3186: PSS FTF issue: PSS & Thread-Safety Do EJB-mapped attributes go to the ComponentDefault interface? (pss-ftf) Source: ZeroC (Mr. Bernard Normier, bernard@zeroc.com) Nature: Uncategorized Issue Severity: Summary: The Persistent State Service draft specification does not say anything about thread-safety. For portability, it is necessary to define the guarantees provided by a thread-safe PSS implementation. Proposal -------- A catalog (session or session pool) can be either thread-safe or thread-unsafe. A compliant implementation does not need to provide thread-safe catalogs. All objects provided directly or indirectly by a thread-unsafe catalog are thread-unsafe -- the application must serialize access to any of these objects, typically by using a single thread. (1) A storage object incarnation provided by a thread-safe catalog is like a struct: concurrent reads are safe and do not require any locking by the application; concurrent writes (or a concurrent read and a concurrent write) are not thread-safe -- the application must ensure mutual exclusion to avoid problems. Flushing a storage object is like reading this object. 'Refreshing' a storage object is like updating it. (2) Further, the following Session operations are not thread safe: they are not supposed to be called concurrently, and no thread should be using the target session (or anything in the target session, such as an incarnation or a storage home) when they are called: Session::free_all Session::refresh Session::close TransactionalSession::start TransactionalSession::suspend TransactionalSession::end OTS operations are however safe; for example one thread can call tx_current->rollback() while another thread calls start, suspend or end on a session involved in this transaction, or while a thread is using storage objects managed by that session. Resolution: accepted Revised Text: A catalog (session or session pool) can be either thread-safe or thread-unsafe. A compliant implementation does not need to provide thread-safe catalogs. All objects provided directly or indirectly by a thread-unsafe catalog are thread-unsafe -- the application must serialize access to any of these objects, typically by using a single thread. (1) A storage object incarnation provided by a thread-safe catalog is like a struct: concurrent reads are safe and do not require any locking by the application; concurrent writes (or a concurrent read and a concurrent write) are not thread-safe -- the application must ensure mutual exclusion to avoid problems. Flushing a storage object is like reading this object. 'Refreshing' a storage object is like updating it. (2) Further, the following Session operations are not thread safe (for a given session): they are not supposed to be called concurrently, and no thread should be using the target session (or anything in the target session, such as an incarnation or a storage home) when they are called: Session::free_all Session::refresh Session::close TransactionalSession::start TransactionalSession::suspend TransactionalSession::end OTS operations are however safe; for example one thread can call tx_current->rollback() while another thread calls start, suspend or end on a session involved in this transaction, or while a thread is using storage objects managed by that session. Rationale: (1) Concurrent writes (or a read and a write) _within the same transaction_ is extremely rare -- if PSS implementations were to provide mutual exclusion, we would penalize the common usage (single-threaded access or maybe concurrent reads) for this unusual usage. (2) Since calling these operations concurrently is wrong or at least dubious, we can avoid some locking in the PSS implementation by declaring them not thread-safe. Revised Text: Create a new paragraph "2.6, Thread Safety", with the text above. Actions taken: January 7, 2000: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 07 Jan 2000 14:41:33 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: PSS FTF issue: PSS & Thread-Safety Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pk_d9)K=e9~&/e9`@_d9 The Persistent State Service draft specification does not say anything about thread-safety. For portability, it is necessary to define the guarantees provided by a thread-safe PSS implementation. Proposal -------- A catalog (session or session pool) can be either thread-safe or thread-unsafe. A compliant implementation does not need to provide thread-safe catalogs. All objects provided directly or indirectly by a thread-unsafe catalog are thread-unsafe -- the application must serialize access to any of these objects, typically by using a single thread. (1) A storage object incarnation provided by a thread-safe catalog is like a struct: concurrent reads are safe and do not require any locking by the application; concurrent writes (or a concurrent read and a concurrent write) are not thread-safe -- the application must ensure mutual exclusion to avoid problems. Flushing a storage object is like reading this object. 'Refreshing' a storage object is like updating it. (2) Further, the following Session operations are not thread safe: they are not supposed to be called concurrently, and no thread should be using the target session (or anything in the target session, such as an incarnation or a storage home) when they are called: Session::free_all Session::refresh Session::close TransactionalSession::start TransactionalSession::suspend TransactionalSession::end OTS operations are however safe; for example one thread can call tx_current->rollback() while another thread calls start, suspend or end on a session involved in this transaction, or while a thread is using storage objects managed by that session. Rationale: ---------- (1) Concurrent writes (or a read and a write) _within the same transaction_ is extremely rare -- if PSS implementations were to provide mutual exclusion, we would penalize the common usage (single-threaded access or maybe concurrent reads) for this unusual usage. (2) Since calling these operations concurrently is wrong or at least dubious, we can avoid some locking in the PSS implementation by declaring them not thread-safe. Regards, Bernard