Allows to use different annotation based injection and configuration associated with event container. An event container that performs polling receive operation (for example blocking take) at a constant interval based on a given template and invokes a custom listener. Configures the polling container to work under a transaction. The transaction manager will be used to start and commit (on success) or rollback (on failure) a transaction. The scope of the started transaction is the receive operation and the even listener invocation. The trigger receive operation is executed before the transaction is started. The trigger operation handler (if set) is called before a tranasction is started, and only if it returns a non null value, the transaction + receive operation + event invocation will be performed. The receive operation handler controls the receive operation (which results in an Object representing the event) implementation. Defaults to a Single take blocking operation. A handler for exceptions raised by the listener. The template that will be used by the receive operation handler to take/read/... event data from the Space. A sql query that will be used by the receive operation handler to take/read/... event data from the Space. The Space data event listener that will be used to handle data events caused by the receive operation handler. Set the timeout to use for receive calls, in milliseconds. The default is 60000 ms, that is, 1 minute. NOTE: This value needs to be smaller than the transaction timeout used by the transaction manager (in the appropriate unit, of course). Specify the interval between recovery attempts, in milliseconds. The default is 5000 ms, that is, 5 seconds. Specify the number of concurrent consumers to create. Default is 1. Specifying a higher value for this setting will increase the standard level of scheduled concurrent consumers at runtime: This is effectively the minimum number of concurrent consumers which will be scheduled at any given time. This is a static setting; for dynamic scaling, consider specifying the "maxConcurrentConsumers" setting instead. Raising the number of concurrent consumers is recommendable in order to scale the consumption of events. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume events. Specify the maximum number of concurrent consumers to create. Default is 1. If this setting is higher than "concurrentConsumers", the listener container will dynamically schedule new consumers at runtime, provided that enough incoming messages are encountered. Once the load goes down again, the number of consumers will be reduced to the standard level ("concurrentConsumers") again. Raising the number of concurrent consumers is recommendable in order to scale the consumption of events. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume events. Specify the maximum number of events to process in one task. More concretely, this limits the number of event reception attempts per task, which includes receive iterations that did not actually pick up a event until they hit their timeout (see "receiveTimeout" property). Default is unlimited (-1) in case of a standard TaskExecutor, and 1 in case of a SchedulingTaskExecutor that indicates a preference for short-lived tasks. Specify a number of 10 to 100 messages to balance between extremely long-lived and extremely short-lived tasks here. Long-lived tasks avoid frequent thread context switches through sticking with the same thread all the way through, while short-lived tasks allow thread pools to control the scheduling. Hence, thread pools will usually prefer short-lived tasks. Specify the limit for idle executions of a receive task, not having received any event within its execution. If this limit is reached, the task will shut down and leave receiving to other executing tasks (in case of dynamic scheduling; see the "maxConcurrentConsumers" setting). Default is 1. Within each task execution, a number of event reception attempts (according to the "maxEventsPerTask" setting) will each wait for an incoming event (according to the "receiveTimeout" setting). If all of those receive attempts in a given task return without an event, the task is considered idle with respect to received events. Such a task may still be rescheduled; however, once it reached the specified "idleTaskExecutionLimit", it will shut down (in case of dynamic scaling). Raise this limit if you encounter too frequent scaling up and down. With this limit being higher, an idle consumer will be kept around longer, avoiding the restart of a consumer once a new load of messages comes in. Alternatively, specify a higher "maxMessagePerTask" and/or "receiveTimeout" value, which will also lead to idle consumers being kept around for a longer time (while also increasing the average execution time of each scheduled task). If set to true will perform snapshot operation on the provided template before invoking the receive operation. Defaults to true. If set to true will pass an array value returned from a 'receiveOperationHandler' directly to the listener without "serializing" it as one array element each time. Defaults to false An event container that performs asynchronous polling receive operation (for example async take) at a constant interval based on a given template and invokes a custom listener. Configures the polling container to work under a transaction. The transaction manager will be used to start and commit (on success) or rollback (on failure) a transaction. The scope of the started transaction is the receive operation and the even listener invocation. The trigger receive operation is executed before the transaction is started. The receive operation handler controls the asynchronous receive operation. operation. A handler for exceptions raised by the listener. The template that will be used by the receive operation handler to take/read/... event data from the Space. A sql query that will be used by the receive operation handler to take/read/... event data from the Space. The Space data event listener that will be used to handle data events caused by the receive operation handler. Set the timeout to use for receive calls, in milliseconds. The default is 60000 ms, that is, 1 minute. NOTE: This value needs to be smaller than the transaction timeout used by the transaction manager (in the appropriate unit, of course). Specify the number of concurrent consumers to create. Default is 1. If set to true will perform snapshot operation on the provided template before invoking the receive operation. Defaults to true. An event container that uses notifications (also known as event session) in order to register for events based on a template and generating events to a custom listener. Configures the notify container to work under a transaction. The transaction manager will be used to start and commit (on success) or rollback (on failure) a transaction. The scope of the started transaction is *after* the notification was received. If a transaction rollback occurs, the notification delivery will not be rolled back, just the listener operations (that operate under the transaction). A handler for exceptions raised by the listener. Controls which operation will cause for notifications to be sent. Defaults to write operations (and once set, will only use the configured operations). Write operation will cause this listener to be invoked. Update operation will cause this listener to be invoked. Take operation will cause this listener to be invoked. Lease expiration operation will cause this listener to be invoked. Matched entries that no longer match the template will cause this listener to be invoked. Allows to control the batching of notifications. Once configured, notifications will be sent in batches. The notifications will be sent once either the number of notifications breaches the size value or the time the notifications are queued breaches the time attribute (in milliseconds). If set, turns batching event notifications where the server space accumulates notifications to be sent and then send them in batch. The batch size controls the number of notifications that will be batched before they are sent. Note, if setting this property the 'batch time' must be set as well. If set, turns batching event notifications where the server space accumalates notifications to be sent and then send them in batch. The batch time controls the elapsed time until the batch buffer is cleared and sent. The time is in milliseconds. Note, if setting this property the 'batch size' must be set as well. If configured will renew the notification registration. If set the true, will automatically renew the notification registration. Sets the timeout for the notificaiton registration. Defaults to FOREVER. Sets a reference to a bean that is a lease renew listener. Allows to configure an implementation of com.j_spaces.core.client.INotifyDelegatorFilter that will be sent to the server and filter notification on the server side. The template that will be used to register for notifications. The template that will be used to register for notifications. The Space data event listener that will be used to handle data events caused by notifications. Controls the communication type of how to send the notifications. Defaults to UNICAST. Controls how notification are propagated from the space to the listener. Unicast propagation uses TCP unicast communication which is usually best for small amount of registered clients. This is the default communication type. Controls how notification are propagated from the space to the listener. Same as unicast in terms of communication protocol but uses a single client side multiplexer which handles all the dispatching to the different notification listeners. Controls how notification are propagated from the space to the listener. Multicast propagation uses UDP multicast communication which is usually best for large amount of registered clients. Note, when using multicast notifications make sure to enable the multicast worker within the Space. Determines if events arrives in the same order they were triggered by the space "server". Note, for a full fifo based ordering the relevant entries in the space should be configured to be fifo as well. Controls if the notifications will be guaranteed (at least once) in case of fail over. If using a replicated space controls if the listener that are replicated to cluster members will raise notifications. If using a replicated space controls if the listener will be replicated between all the replicated cluster members. If set to true will remove the event from the space using take operation. Default is false. If set to true, will not propagate the event if the take operation returned null (meaning that other notifications has already taken it). This flag only makes sense when 'perform-take-on-noitify' is set to true. If set to true will perform snapshot operation on the provided template before invoking the receive operation. Defaults to true. If set to true will pass an array value returned from a 'receiveOperationHandler' directly to the listener without "serializing" it as one array element each time. Defaults to false The GigaSpace which controls which Space this event container will use. If set the true will cause the event container to be active only when working against a primary space (in cases when working with a remote Space, it is always considered to be primary). Defaults to true. Set whether this container will start once instantiated. Default is true. Set to false in order for this container to be started using start(). Sets the transaction manager this event container will use to manage transactions. Specify the transaction name to use for transactional wrapping. Default is the bean name of this listener container, if any. Specify the transaction timeout to use for transactional wrapping, in seconds. Default is none, using the transaction manager's default timeout. ". ]]> ". ]]> The receive operation handler controls the receive operation (which results in an Object representing the event) implementation. Defaults to a Single take blocking operation. ". ]]> The receive operation handler controls the asynchronous receive operation. ". ]]> The trigger operation handler (if set) is called before a transaction is started, and only if it returns a non null value, the transaction + receive operation + event invocation will be performed. ". ]]> A custom handler to handle exception raised by the event listener. ". ]]> The lease time the result will be written under (in milliseconds). Defaults to FOREVER. Sets if the write operation will perform an update in case the entry result already exists in the space. Default to true. Sets the update timeout (in milliseconds) in case the flag 'update-or-write' is set to true. Sets the Spring scope of this listener. Defaults to singleton. A SpaceDataEventListener that can be configured with a delegate which has one (or more) of its methods annotated with @SpaceDataEvent. ". ]]> A SpaceDataEventListener that can be configured with a delegate which has one of its methods marked as the listener method (using the 'method-name' attribute). ". ]]> The method name that will be invoked when an event occurs.