Developing an application with multiple concurrent frames raises issues about transaction management. If operations in the frames are related, you might want to maintain a single transaction for the entire application. A single transaction forces a commit or rollback statement issued in any one of the open frames to affect all open transactions. Designing applications whose transactions do not span frames or event blocks is recommended, however, to improve concurrency.

However, maintaining one transaction throughout several concurrent frames also can cause locking conflicts. If operations in the frames are not related, you might want to open a different database session (each with its own transaction) for each frame.

In a single OpenROAD application, you can use multiple sessions to provide separate database sessions for concurrent transactions (with the same or different flag settings) in the same database or to connect each session to a different database.

Although you can open any number of sessions, you should limit the number of open sessions according to your transaction processing needs. If you need to access data from different databases, you need multiple connections to support this access. However, you should not open more sessions than you can easily manage because:

When using database events, register them for every open session that is to receive them. Each frame receives database events only on its current connection. If you register a database event and then switch to another session that did not register the event, the frame will not receive the database event.