The CallbackHandler interface is invoked when any database event occurs. A default callback handler is provided, which basically does nothing. You should implement a custom CallbackHandler to register important events. The callback is invoked on the thread that is processing the event. To receive callbacks for database changes, you must register a CallBackHandler with the generated database class, the entity class, or both. You can create a handler by extending the DefaultCallbackHandler class or by implementing the com.sybase.persistence.CallbackHandler interface.
In your handler, override the particular callback that you are interested in (for example, void onReplayFailure(java.lang.Object entity) ). The callback is executed in the thread that is performing the action (for example, replay). When you receive the callback, the particular activity is already complete.
Callback | Description |
---|---|
void onReplayFailure(java.lang.Object entity) |
This method is invoked when a replay request fails. Note: CallbackHandlers registered for both the MBO
class of the entity and the Package DB are invoked.
Parameters:
|
void onReplaySuccess(java.lang.Object entity) |
This method is invoked when a replay request succeeds. Note: CallbackHandlers registered for both the MBO
class of the entity and the Package DB are invoked.
Parameters:
|
int onSynchronize(ObjectList groups, SynchronizationContext context) |
This method is invoked at different stages of the synchronization. The status of the synchronization context specifies the stage of the synchronization. Parameters:
Returns: Either SynchronizationAction.CONTINUE or Synchronization.CANCEL. If
SynchronizationAction.CANCEL is returned, the
synchronize is cancelled if the status of the synchronization
context is one of the following.
|
void onMessageException(java.lang.Exception ex) |
This method is invoked when an exception occurs in the processing of a message. Note: In DefaultCallbackHandlers, onMessageException re-throws the
Exception so that the messaging layer can retry the message. The
application developer has the option to implement a custom
CallbackHandler that does not re-throw the exception, based on
exception types or other conditions, so that the message is not
retried.
Parameters:
|
This code shows how to create and register a handler to receive callbacks:
public class MyCallbackHandler extends DefaultCallbackHandler { // implementation } CallbackHandler handler = new MyCallbackHandler(); <PkgName>DB.registerCallbackHandler(handler);