Persistence/Aspects

[adrian.brock]

Related to aspects.

The persistence should use the same code as EJBs.
This is implemented as interceptors for
locking, caching, synchronization, etc.

Other aspects will add authentication, authorization,
transactions, logging, etc.

Regards,
Adrian

[hchirino]

A quick note on JMS's cacheing requirments.

The cache will be holding JMS messages. A JMS message is composed of 2 parts, the header information and the body of the message. The cache needs to be able to passivate the body but keep the headers. If a receiver is using a message selector against a queue, the message headers for the messages in that queue will be in constant use.

Regards,
Hiram

[farooqui]

Where is the persisted message going to be ... hopefully on loacl disk, right? Are you guys thinking of local indexed entity to store/persist messages in (queue/topic) like MQSeries. Each queue for instance in MQSeries is a mini-database on the local disk.
If you are just caching the headers, even that becomes quite a burdon in a high load situation. I think if you stick with a indexed file system object for a queue that is intelligently searcheable and make use of nio, you will actually cut out complexity of caching just headers and performance will be just as good as if you cached headers because in that case you are still going to the file system to retrieve th message body. I don't believe this is where any MOM product spends bulk of its time unless the indexing and search scheme is not very well thought out.
I would suggest go to the file system for all persistent/durable messages and keep as many non durable messages completely in memory (headers and all) as you can. Limit message sizes however. JMS spec does not say what message sizes limits should be, that's left upto the provider.
Sincerely,
Abid