![]() This can be achieved with only a few lines of code and without a need to expand the technical stack to additional technology such as Zookeeper. If multiple nodes can receive an HTTP message that is meant for this leader node to process, those nodes can now forward this call via a JDBC message store which notifies the leader instantaneously. For example, one could use Spring integration’s LockRegistryLeaderInitiator to determine a node that executes unshared work. When creating a multi-node application that already uses Postgres, this can be used as an easy way to communicate between VMs. GetPassword()).unwrap(PgConnection.class) Ĭhannel.subscribe(message -> (īefore, inter-JVM communication like this was previously only possible by polling the channel for new messages while the above mechanism allows for quasi-instant communication among different VMs. New PostgresChannelMessageTableSubscriber(() -> PostgresChannelMessageTableSubscriber subscriber = The message allows to send a message with any serializable payload to a given channel as follows: By defining a trigger, similarly to the one above, as suggested in Spring integration’s schema-postgres.sql file, Spring integration allows for receiving messages that are sent via a regular JdbcChannelMessageStore. But as of today, it only offers polling messages, or to receive push messages when operating on the same queue object within a single JVM. Spring integration does already offer a JDBC-based queue implementation. This functionality will be available in Spring integration with imminent arrival of version six. Using Spring integration’s JDBC message queue on Postgres This might not always be possible, for example on Kubernetes when multiple replicas share a common host. However, this requires that the database can actively call the notified application on a given host and port. With Oracle, for example, the database does not require a dedicated connection. With this downside, the approach of Postgres does also bring a less obvious upside. Quite the opposite, if the listening for notifications can substitute frequent polling against the database, this approach might even free resources. As connections for receiving notifications do often run idle and require few machine resources, this is not normally a consequential change. It might therefore become necessary to increase the maximum number of allowed concurrent connections in the Postgres server instance. For this reason, a Postgres server might start rejecting new connection attempts if too many JVMs already occupy a dedicated connection for listening for notifications. Note that this also occupies a full connection on the Postgres server where connections typically are pooled, as well. Instead, one should create a dedicated Connection via the DriverManager API. This requires that the connection is long-lived, which does not normally play well with pooled DataSources. This is due to the connection being used for sending notifications back via the channel that the JDBC client established when opening a connection and executing the LISTEN statement. One caveat with Postgres’ notification mechanism is that it typically requires the creation of a dedicated Connection for receiving notifications. ![]() Postgres notifications and connection pooling This way, one or several listeners can be notified on the arrival of new messages, for example as replicas within a Kubernetes deployment. For a simple hello-world example, consider a JVM to listen on a given hello_world_channel: And of course these commands can be issued via JDBC. One such feature is the LISTEN and NOTIFY mechanism which allows for sending asynchronous messages across database connections. But beyond that, Postgres implements many other, non-standardized features that can also be executed via its extension upon SQL. Postgres is, of course, a relational database that implements a large fraction of the SQL standard. It also looks into using this queue for communicating among replicas on a Kubernetes deployment, and into implementing a generic task processing framework. ![]() Therefore, this article looks into Postgres’ lightweight notification mechanism and discusses how it can be leveraged to implement a simple, but effective push-based message queue. But with advancements in relational databases, does this claim still stand up to scrutiny? Looking at modern versions of Postgres, the answer is often no. Databases are no message queues is a well-established claim that has been discussed in many blog postings and conference presentations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |