Cosmo 1.0 Service Layer Notes

The service layer consists of a group of interfaces and implementations that provide high-level apis for the application to use. For Cosmo it consists of UserService and ContentService .

UserService contains an api for managing users and ContentService contains an api for managing items.

The implementations for these services are found in org.osaf.cosmo.service.impl

StandardContentService

StandardContentService implementation uses a LockManager to synchronize updates to collections. The morse code protocol implementation requires that access to collections must be synchronized. Two threads can't simultaneously update the same collection (add/update/remove item or modify collection details). For each method that updates a collection, locks to all collections involved must be obtained before the transaction completes. The default implementation for LockManager is SingleVMLockManager , which is a simple lock manager that works in a single vm (won't work in a clustered environment). Different lock manager implementations can easily be plugged-in using Spring.

Truth be told, the current LockManager implementation is basically broken. It turns out even if you get a lock, the transaction will fail due to optimistic locking. This area needs some work.

Transactions

Each service implementation is configured in Spring, and has transactional advice wrapped around it (using spring aop). This means the transaction boundary in Cosmo is at the service level. Each exposed service method is executed in a new transaction. Typically an update request results in the use of a single update service call. This ensures that if the service call fails, the transaction will be rolled back and the database will be returned to the state before the service call. If multiple service calls are required for updates, then it is time to add a new service api that encompasses all the necessary logic for the transaction to be atomic.

-- RandyLetness - 25 Jun 2008