Hi Alexey, I did poke around on continuous queries before. Based on your recommendation I will take another look to see if they solve my architecture pattern.
Transaction listeners/messages are a common pattern with other technologies. Here is a suggestion of how Ignite might evolve to be better in this area: I envision an Ignite server in the grid acting as a transaction coordinator. (I have Cassandra behavior in mind when thinking through this). The client code may issue the final "commit" API call, but this would simply send an indicator to the coordinator in the grid which would handle the commit across the grid with the data owners. Then, this coordinator could generate a transaction message to any registered listeners AND return the transaction status back to the client. Guessing about how Ignite works today, there appears to be an assumption that the client...even the end user client code...has to be the coordinator of the transaction. But I don't think it has to remain this way. A model more similar to Cassandra behavior (I'm not talking Cassandra transactions - it only has lightweight, query specific transactions - but more the model of the way a client interacts with the Cassandras cluster), might be an interesting model for Ignite to evolve towards. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/listening-for-events-on-transactions-tp5346p5460.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
