Re:[JBoss-dev] JBossMQ JDBC2 Persistence Manager

[Aaron L. <aar...@ob...>]

Ulf,
   I've been thinking of doing something similar to what you've described.  
Would you like to work together on this?

Aaron

On Wednesday 14 May 2003 11:14 am, you wrote:
> Good input :-) I already have thought about writing that code, but still I
> am not sure that I have enought understanding of the internal interactions
> between the message cache and the persistence manager  ( e.g. threading
> and message reference handling issues like softening, hardening, release,
> ... ) This might take some time for implementation and much more time for
> testing...
>
>
>
>
>
> "Adrian Brock" <ad...@jb...>
> Gesendet von: jbo...@li...
> 14.05.2003 15:28
> Bitte antworten an jboss-development
>
>
>         An:     <jbo...@li...>
>         Kopie:
>         Thema:  RE: [JBoss-dev] JBossMQ JDBC2 Persistence Manager
>
>
> This is a good optimization,
> that will help JBossMQ scale better
> to a larger number of subscribers.
>
> You can use the internal header.messageId
> as the key to the blob.
>
> Don't do this for Queues.
> Persistence would require two write
> operations when only one is necessary.
>
> Do you want to write this as jdbc3 persistence?
>
> Regards,
> Adrian
>
> -----Original Message-----
> From: jbo...@li...
> [mailto:jbo...@li...] On Behalf Of
> ulf...@mo...
> Sent: 14 May 2003 11:11
> To: jbo...@li...
> Subject: [JBoss-dev] JBossMQ JDBC2 Persistence Manager
>
>
>
> Is anybody out there with detailed understanding of the JBossMQ JDBC2
> Persistence Manager ( I am sure there is :-) ? I would like to discuss
> an optimization of persistent BLOB message storage strategy for JMS
> topics. We want to use JBossMQ in production and we have to rely on
> persistent messaging via topics with high number of durable subscribers.
>
>
> Currently  when persisting a new message for a topic a complete copy of
> that message is stored as separate entry for EVERYdurable subscription
> in jms_messages (e.g. sending a message to a topic with 10 durable
> subscribers leads to 10 message copies INCLUDING the large messageblob
> in the JDBC message store ). This strategy has severe performance
> impacts because BLOB inserts are high-cost-operations (cpu usage,
> storage usage).
>
> My idea is to store ONLY ONE copy of the messageblob in a separate table
> (e.g. jms_messageblobs with columns blobid, messageblob ) an simply
> reference that single blob from all messageentries in jms_messages that
> share that identical blob. So in the above example a message send to a
> topic would lead to 10 SMALL messageentries in  jms_messages and only
> one blob entry in jms_messageblobs, saving 9 heavy-weight blob inserts !
>
>
> Another benefit of that strategy maybe would be an optimized / lasy blob
> deletion from the database. If a persistent message has been
> successfully delivered to its consumer, the persistence manager only
> removes the corresponding small messageentry in  jms_messages. A timed
> background  thread then removes all unused blobs ( meaning no more
> references from jms_messages.blobid ) with a single SQL statement like
> DELETE FROM jms_messageblob WHERE blobid NOT IN( SELECT DISTINCT blobid
> FROM jms_messages ).
>
> Any comments on this idea ?
>
> Regards
> Ulf
>
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Jboss-development mailing list
> Jbo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development