JMS specific columns in DB

[timfox]

Currently there are a few JMS specific columns in the database, e.g.

JMS_MESSAGE table:
destination
reply_to
correlation_id
jms_type

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.

Having no JMS specific stuff in the db schema would have the advantage of enabling us to more cleanly support other message formats (e.g. AMQP) without changing the schema.

It would also remove any JMS dependencies from JDBCPersistenceManager.

Comments please?

[jeffdelong]

Is this table required to support persistent queues?

[timfox]

JMS_MESSAGE stores messages which logically live in either JMS queues or JMS durable topic subscriptions.

[clebert.suconic]

You will probably need to store the header on the database anyway, right?

I guess putting this to a single field is not going to eliminate the dependency anyway as you still need the information.

Those fields are nullable anyway... if using any other protocol in the future we could just keep them NULL.

Maybe if you want to separate things you could add the word JMS_ to these fields then it's clear what they are for.

[timfox]

If we're going to allow for them being null in the future may as well get rid of them now.

I don't want a load of garbage in the db.

[jeffdelong]

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.

[clebert.suconic]

These fields are Nullable anyway now.

I just don't like the idea of composed fields on the DB.

I prefer having the DB self documented.

Maybe it's something I inherited from the days I was a consultant working with business systems.

[timfox]

The thing is, JBoss Messaging is supposed to be a generic messaging system.

Currently the DB schema has a depenency on JMS, which is wrong.

If we support AMQP for example, are we going to add 10 more fields AMQP_Fluxfactory, AMQP_WibbleQuotient etc?

I don't think so.

All the generic properties will still be columns, e.g. delivery count, blah blah

[timfox]

Also if don't get rid of them now, it will be very hard to do so later on.

Since people may have written other systems / processes which rely on them.

I don't want to be in a situation where we end up with a crappy schema we have to live with for ever.

[clebert.suconic]

Well... do as you wish...

I would prefer a separate table.. (1 to 1 relationship) or the extra fields. Composed fields are worse than these extra fields IMO.

[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.

[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 ;)

[ovidiu.feodorov]

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?

[clebert.suconic]

"Ovidiu" 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.

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)

[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