# Using eXtremeDB Database Events and Time-To-Live Features in Python

> As explained in the introduction page, eXtremeDB provides the capability to automatically delete obsolete database objects through the Time-To-Live feature, and to manage database object new, delete, update and checkpoint events. The Python APIs for these features are explained in the sections below.

> ## Time To Live

> Currently the eXtremeDB Python API does not support the Time-To-Live feature.

> ## Event Interfaces

> eXtremeDB applications can respond to data events like creating, updating or deleting database objects. For Python applications the DDL `event` declarations cause applications to receive notification of the following database event types: adding a new object, deleting an object or all objects of a class, checkpoint events and updating an object or a specified field of an object. Events are specific to classes. In other words, a `new` event handler for class A will not receive a notification when an object of class B is added to the database.

> The event declaration in the schema defines what events will trigger application notifications. How the application handles the events is determined at run-time by the event handlers. In Python applications, only asynchronous events are possible.

> ### Asynchronous Event Handling

> In asynchronous event handling, the application spawns a separate thread to handle each type of event. This event thread calls Connection method `waitEvent()` to wait for the specified event. When the event occurs, the runtime releases the thread. Upon releasing the thread, the runtime continues normal processing, so the handler thread runs in parallel with other threads, until it completes its processing and again calls `waitEvent()`.

> There is a small window of possibility for another instance of the event to occur before the event handler has completed its task and calls `waitEvent()` again to wait on the event (events are not queued). This window can be minimized if the handler delegates the processing of the event to yet another thread, allowing the handler thread to immediately wait on the event again. If this risk of an unhandled event cannot be tolerated, the application can maintain a separate table of unhandled events.

> Asynchronous events are activated after the transaction commits. If, within the scope of a single transaction, several objects are added, or deleted, or several fields are updated which have event handlers waiting, all the handlers will be activated simultaneously.

> Then the Python application will start the event handler threads and cause the main application thread to sleep for some milliseconds (100 is usually adequate) in order for the event handler threads to start listening (waiting). Then the main application thread will proceed with normal database processing. When terminating, the application will call Connection method `releaseAllEvents()` to release all events and then stop the event handler threads.