From: <ovi...@jb...> - 2005-12-30 05:01:40
|
We seem to converge. This is the summary of the thread, so far: A channel (org.jboss.messaging.core.Channel) is a transactional mechanism that receives and reliably forwards messages to arbitrary receivers. The channel's responsibilities are to provide atomicity (the channel atomically accepts or discards a set of messages), isolation (it is thread-safe) and most important, durability for reliable messages, which insures the fact that a reliable message can be recovered even if the channel instance crashes. Ideally, a channel should implement this behavior in a smart way, i.e. not wasting extra effort to insure recoverability for non-reliable message, for performance's sake. A channel is responsible for internally managing its state. Because of that, it can apply whatever optimizations it finds fit (spill over, lazy loading, etc., more about this later). The channel's internal component responsible with maintaining state is named, naturally enough, state (org.jboss.messaging.core.State). The channel state only maintains message references. A message reference is a lightweight representative of the message that has a much smaller footprint by avoiding to embed the message payload. The message reference maintains however message attributes such as reliability flag, timestamp, redelivery count, etc. and the full set of headers. The rationale behind this arrangement is to allow the channel to free up memory by dumping message bodies on disk when it runs tight on resources, while still maintaining the message representatives (live data) in memory. The channel state is maintained in memory. However, the state implementation must have access to transactional storage for at least four reasons: 1. It must maintain a transactional log to write ahead messages references as "prepared" and then switch them to a "commited" state when the core transaction commits. 2. In must persist reliable messages (message reference from state and their corresponding message bodies) to insure recoverability. 3. It may need need to persist non-reliable message bodies and dump them from memory in case of memory shortage. 4. Ultimately, it may need to persist even parts of the state itself (message references, reliable and non-reliable) if faced with large quantities of messages. This would allow a channel to maintain an "unlimited" number of messages, regardless of memory constraints (obviously provided that it has access to "unlimited" storage). The channel and the channel state access the transactional storage via an abstraction soon-to-be-renamed called persistence manager. The persistence manager implementation maintains no state. Whatever the final name of this abstraction will be, it must offer an interface that gives access to the functionality described above: transactional log, mandatory storage/retrieval of reliable message bodies (backup data), on-demand storage/retrieval of non-reliable message bodies (spillover data) and storage/retrieval of channel state for eager dumping/lazy loading (live data). The current implementation spreads this behavior among two interfaces (org.jboss.messaging.core.PersistenceManager and org.jboss.messaging.core.MessageStore). This situation will change. Adrian started the process by proposing two new interfaces (TransactionLogDelegate and LazyDelegate). How this component should actually look is the subject of http://www.jboss.org/index.html?module=bb&op=viewtopic&t=73301 which will soon return to. However I won't close this thread until everbody agrees with the summary that I just laid out (or another one resulted from additional iterations). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914880#3914880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3914880 |