Loading ...
Sorry, an error occurred while loading the content.
 

Re: [Firebird-Java] Responding to Firebird events

Expand Messages
  • Roman Rokytskyy
    Jim, I assume that you do not track J2EE world in details, so I will provide some information about the JMS messaging that is quite common in enterprise Java.
    Message 1 of 14 , Jun 1, 2005
      Jim,

      I assume that you do not track J2EE world in details, so I will provide some
      information about the JMS messaging that is quite common in enterprise Java.
      If you know all this, please skip to the suggestions.

      JMS is an abstraction of the messaging middleware that are in use for a
      long, at least that was the reason why it was "invented". The idea behind it
      is to allow Java applications to send and receive messages floating in the
      enterprise (if I understand it correctly, JMS was never targeting desktop
      systems).

      JMS introduces the concept of message producer and message consumer.
      Producers create messages and send them to destinations, consumers receive
      and process messages. Destinations allow multiple producers and multiple
      consumers. A message consists of a headers, properties and a body.

      Two types of destinations are available:

      - queues; in this case producers are called "senders", consumers are called
      "receivers"; a message posted into a queue is guaranteed to be consumed by
      only one consumer.

      - topics; in this case producers are called "publishers" and consumers are
      called "subscribers"; a message posted into a topic is guaranteed to be
      delivered to all cosumers (a multicasting).

      Each consumer can specify a message selector, syntax of which is based on
      SQL92 conditional expression syntax. Message selector filters messages that
      are delivered to consumers.

      Also each message has two delivery modes - persistent and transient.
      Transient messages are allowed to be lost during transmition. Persistent
      messages must be delivered without losses.

      Each message has also expiration time. Messages that were not delivered
      within the specified timeout (in milliseconds) are not delivered at all.

      Topic implementation must also provide a functionality to cache messages for
      so-called durable subscribers. Such subscribers provide an unique ID when
      connecting to a topic, and after some time they are allowed to disconnet. On
      the next connection, when they provide the same unique ID, all messages that
      were not yet "seen" by the subscriber are delivered to it.

      Finally, JMS has a concept of transactions. Message is not considered to be
      consumed until it is acknowledged. On transaction commit all messages posted
      to the destination are delivered to the recepients and all consumed messages
      are acknowledged. So, if some queue consumer crashes during message
      processing, message is not acknowledged and will be delivered to another
      consumer.

      Why did I write that all above?

      First of all, I want to show that event implementation is Firebird is
      functionally a subset of JMS functionality (topics with transactional
      message sending and auto-message acknowledgement). The only difference is
      that equal messages are sent only once.

      Second, I suspect that the properties described above are not unique to JMS,
      but are also available in other messaging middleware. So, maybe we should
      define an API for event handling, including a transaction notification and
      let the messaging middleware to the rest? It can do it more effectively,
      also providing a much richer functionality.

      > But the real bottom line is that if the data in the message can be
      > stale, a client application has to go back to the database anyway, so
      > why bother to send the stale data? Perhaps you might sketch a scenario
      > where stale data is useful.

      No, not stale data. If a message contains some payload, client can already
      make some decision on that data even without accessing the database, for
      example, invalidate the cache. In that case, only one packet is sent from
      server to client, not one packet with event, then request/response for
      isc_dsql_exec2 (assuming that statement is prepared), request/response for
      isc_dsql_fetch and isc_dsql_free to release result set. The main question is
      to find the balance between the price to deliver big message and price to
      maintain the log table including making network requests.

      > No, not at all. I've said a million times that Interbase was designed
      > for a different era, and more capable machines and networks suggest that
      > all original design decisions are subject to review. This is no
      > different. If there are problems that the current mechanism doesn't
      > address that can be solved by an alternative mechanism without
      > introducing a raft of "gotcha's", lets see what we can do.

      I cannot tell that there are problems with events that current mechanism
      cannot solve, but I see the way to improve it by introducing "event manager"
      plugins that will deliver the event using the desired media. Some may use
      UDP multicast, some may use TCP unicast, others can just proxy messages to
      JMS. Idea is to let server handle data and make events management a
      pluggable thing.

      Roman
    • Jim Starkey
      ... Roman, the existing event mechanism is part of the base platform and, as such, isn t a good candidate for a replaceable plugin. I think a better approach
      Message 2 of 14 , Jun 2, 2005
        Roman Rokytskyy wrote:

        >Why did I write that all above?
        >
        >First of all, I want to show that event implementation is Firebird is
        >functionally a subset of JMS functionality (topics with transactional
        >message sending and auto-message acknowledgement). The only difference is
        >that equal messages are sent only once.
        >
        >Second, I suspect that the properties described above are not unique to JMS,
        >but are also available in other messaging middleware. So, maybe we should
        >define an API for event handling, including a transaction notification and
        >let the messaging middleware to the rest? It can do it more effectively,
        >also providing a much richer functionality.
        >
        >

        >I cannot tell that there are problems with events that current mechanism
        >cannot solve, but I see the way to improve it by introducing "event manager"
        >plugins that will deliver the event using the desired media. Some may use
        >UDP multicast, some may use TCP unicast, others can just proxy messages to
        >JMS. Idea is to let server handle data and make events management a
        >pluggable thing.
        >
        >
        Roman, the existing event mechanism is part of the base platform and, as
        such, isn't a good candidate for a replaceable plugin. I think a better
        approach is to think about what extensions or hooks would be necessary
        to the UDF mechanism to make a JMS implementation possible. At a
        minimum, I would think it would require:

        * Per database instance memory
        * Notification of transaction commit, rollback, and prepare
        * Notification of upcoming database shutdown

        There are probably more. The goal of the exercise isn't just to provide
        the hooks for a full functionality JMS interface, but to also support
        other external communication facilties.

        I suggest we move the discussion to the Architecture list.

        --

        Jim Starkey
        Netfrastructure, Inc.
        978 526-1376
      Your message has been successfully submitted and would be delivered to recipients shortly.