You're looking at the docs for gemfireXD, which is a sql database built on top of gemfire. Check out the docs for geode here http://geode.docs.pivotal.io/docs/
With geode functions (the equivalent of data aware procedures) 1. FunctionService.onRegion will make sure all of your data is covered exactly once. So with a replicated region, that means it's executed on a single node. With a partitioned region, it will run on as many nodes as it takes to cover all of the buckets. You can choose to execute the function on only the primaries by setting optimizeForWrite to be true. Replicated regions don't have primaries; it's a multi-master system. 2. You can execute a function within a transaction - but be aware that geode does not support distributed transactions so if updates need to span more than one member you can't do that in a single transaction. -Dan On Thu, May 5, 2016 at 6:52 AM, Amit Shah <[email protected]> wrote: > I have a couple of queries on how DAP > <http://gemfirexd.docs.pivotal.io/latest/developers_guide/topics/server-side/data-aware-procedures.html#data-aware-procedures> > and SYS listeners > <http://gemfirexd.docs.pivotal.io/latest/reference/system_procedures/add_listener.html> > work. > > > 1. Event Listeners - Can the event listener be configured to be > executed *only* on the primary node in the case when the table is > replicated on multiple nodes? > 2. Data Aware Procedure - I wanted to understand the behavior of a > data aware procedure code execution when > 1. It is called ON a table that is replicated on multiple nodes? Would > the procedure execute on all the replicated nodes or only on the primary > node? If it executes on all nodes, is there a way to configure it to > execute on only on the primary node? > 2. I would like the DAP to join the transaction started by the jdbc > client that invoked it. This could also lead to recursive invocation of > the > procedure to perform DML queries on multiple tables. Is that > theoretically > possible? > > > I would be helpful if someone could share their insights on this. > > Thanks, > Amit >
