February 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

"clebert.suconic(a)jboss.com" wrote : | | It's even worse... | | If you use composed fields... and if you need eventually to perform a JOIN... | you will need to do something like | WHERE SUBSTRING(COMPOSED_FIELD,1,5) = "DESTINATION" | | or something like that... | | Read my previous answer. Anything that is used in joins is in it's own field. The core "destination" is the channel. This what the core is concerned with. The Jms destination means nothing to the core, it's just a piece of baggage that's passed around. That's pretty much already the case. anonymous wrote : | If you have 100 systems... it's better to have 100 columns than a single column with 100 substrings to deal with. :-) | Who said you'd have to deal with substrings? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011812#4011812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011812

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | Keeping information like "destination" in its own main table field will speed up queries, isn't it? Otherwise, you'll need to use a JOIN instead of a simple SELECT. | Destination is never used in queries. The core joins on channel id only (you can think of this as the real core destination) which is in it's own column. anonymous wrote : | Stuffing non-generic information as message headers will impact performance. It's difficult to say how much, without proper measuring, though. | Not so. I wouldn't have suggested it, if that was the case. anonymous wrote : | This is what migration utilities are for. We won't have to live forever with it, we will just have to go through the trouble of writing a migration tool. We need to do this while migrating from 1.0 to 1.2 anyway. | We don't need this for 1.2 since we have specifically said no compatibility until after 1.2. This is why it needs to be done now. anonymous wrote : | Personally, I don't believe in the "perfect generic design" that "fits every possible case". We need to have a plan for evolution, not perfection, which is unattainable. | Who said it was a perfect gerneric design? It is just a better design than before. An "evolution" in your words. And please, we don't have weeks to debate this....... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011807#4011807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011807

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by apwalker

Can't you implement the Persistence for a specific message type (JMS, AMQP,etc) as a strategy in the Persistence Manager and then you can have a custom schema per message type implementation. So as you add support for different messaging systems you just add a persistence strategy for it. Just a thought, might be maintenance hell though. --Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011749#4011749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011749

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by clebert.suconic＠jboss.com

It's even worse... If you use composed fields... and if you need eventually to perform a JOIN... you will need to do something like WHERE SUBSTRING(COMPOSED_FIELD,1,5) = "DESTINATION" or something like that... Besides... if you need to support a different system, you change PersitenceManager, or implement a new one. Also... Tim wrote : Well... with your logic, eventually you would end up with 100 column tables, some columns null, some not depending on which particular message type is used. If you have 100 systems... it's better to have 100 columns than a single column with 100 substrings to deal with. :-) also.. you could have something pluggable that would enable/disable fields creation according to used features. (if that happens some day) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011727#4011727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011727

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by ovidiu.feodorov＠jboss.com

Tim wrote : | As part of http://jira.jboss.com/jira/browse/JBMESSAGING-739 I am considering removing those columns and just storing those values as core headers in the message. | | E.g. there would be a core header called JBM.JMS.Destination (or whatever), which had destination as its value. | Keeping information like "destination" in its own main table field will speed up queries, isn't it? Otherwise, you'll need to use a JOIN instead of a simple SELECT. Stuffing non-generic information as message headers will impact performance. It's difficult to say how much, without proper measuring, though. Tim wrote : | I don't want to be in a situation where we end up with a crappy schema we have to live with for ever. | This is what migration utilities are for. We won't have to live forever with it, we will just have to go through the trouble of writing a migration tool. We need to do this while migrating from 1.0 to 1.2 anyway. Personally, I don't believe in the "perfect generic design" that "fits every possible case". We need to have a plan for evolution, not perfection, which is unattainable. Could you please jot down the schema, as you think it should be, before going ahead and changing code? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011700#4011700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011700

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by julien＠jboss.com

I think I fixed the issues with CMS, we'll see how it goes in the next execution of the testsuite. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011665#4011665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011665

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: http://jira.jboss.org/jira/browse/JBMESSAGING-808 - Fail

by timfox

"clebert.suconic(a)jboss.com" wrote : that works (besides the other synchronized case where ACKed already happened). | | I'm doing these changes: | | - Adding a method on the postOffice, as I didn't want to deal with PM on the ServerConnectionEndpoint neither to expose PM on PostOffice: | It's ok to talk to the pm directly. I don't see the value of adding methods to the postoffice if they then just talk directly to the pm. anonymous wrote : | - On FailoverValveInterceptor, I'm adding a header to the JBossMessage when a failure occurs. | | - I will also set a flag on TransactionRequest (protected boolean retry) but I will need to change the wireFormat a little bit to cope with that. I would prefer send() and sendTransaction() to be dealt with consistently. I.e. add a new parameter in both cases rather than a header. Yes, this would involve changes (add a boolean) to the wireformat and change of the signature of send() and sendTransaction(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011664#4011664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011664

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: http://jira.jboss.org/jira/browse/JBMESSAGING-808 - Fail

by clebert.suconic＠jboss.com

that works (besides the other synchronized case where ACKed already happened). I'm doing these changes: - Adding a method on the postOffice, as I didn't want to deal with PM on the ServerConnectionEndpoint neither to expose PM on PostOffice: boolean messageExists(long messageId) throws Exception; - On FailoverValveInterceptor, I'm adding a header to the JBossMessage when a failure occurs. - I will also set a flag on TransactionRequest (protected boolean retry) but I will need to change the wireFormat a little bit to couple with that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011661#4011661 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011661

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

Well... with your logic, eventually you would end up with 100 column tables, some columns null, some not depending on which particular message type is used. Yuck, no thanks :) If people really want that kind of perverse monstrosity they can write a JDBCPersistenceManager implementation that does that ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011623#4011623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011623

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

"jeffdelong" wrote : Might this information be useful to a human that is looking at messages that are sitting in a queue? It would be easier to read from a table than from the message header. Getting rid of the JMS specific fields doesn't preclude the above. It's quite possible that you could write a PersistenceManager implementation that stores headers (whether JMS or not) in a different table where they could be looked at by a human. This would probably be hideously slow, but someone may want it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011616#4011616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011616

19 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007