JBM 2.0 JDBCPersistenceManager - volunteers?

[timfox]

Hello All-

For JBM 2.0, the main persistence mechanism is not via JDBC, but we still need to provide a simple JDBC PersistenceManager implementation, that uses JDBC.

I'm looking for volunteers to implement this.

The Persistence Manager interface is pretty simple, currently :

public interface PersistenceManager
{
 /**
 * Persist a message reference in the specified queue also persisting the message if it is not already
 * persisted
 * @param queue The queue to persist it in
 * @param ref The MessageReference to persist
 * @param tx The transactional context, or null if no transactional context
 * @throws Exception
 */
 void addReference(PersistenceTransaction tx, Queue queue, MessageReference ref) throws Exception;

 /**
 * Remove a message reference from persistent storage for the specified queue, also removing the the
 * associated message if it is not in any more queues
 * @param queue The queue to remove from
 * @param ref The MessageReference to remove
 * @param tx The transactional context, or null if no transactional context
 * @throws Exception
 */
 void removeReference(PersistenceTransaction tx, Queue queue, MessageReference ref) throws Exception;

 /**
 * Update the delivery count for the specified MessageReference
 *
 * @param queue The queue
 * @param ref The MessageReference
 * @throws Exception
 */
 void updateDeliveryCount(Queue queue, MessageReference ref) throws Exception;

 /**
 * Create a PersistenceTransaction
 * @return The PersistenceTransaction
 * @throws Exception
 */
 PersistenceTransaction createTransaction() throws Exception;

 /**
 *
 * @param reference
 * @return
 */
 boolean duplicateExists(MessageReference reference);

 /**
 * Load the specified queues from persistent storage
 * @param queues The map of queues to load
 * @throws Exception
 */
 void loadQueues(Map<Long, Queue> queues) throws Exception;
}

The JDBCPersistenceManager implementation should use HIbernate (at least the dialects) to actually do the performance - we don't want to have to provide different configs for different databases as we did in JBM 1.x.

Any volunteers?

[bershath27]

hi Tim,
yes, as we've already discussed, i'll take care of this and do this part. it's a pleasure.

Tyronne Wickramarathne

[timfox]

Great :)

[timfox]

Ok, I have created a JIRA task and assigned to you: http://jira.jboss.org/jira/browse/JBMESSAGING-1172

First thing to do before diving into real code would be to put together wiki page(s) with your proposed design, then we can discuss.

[timfox]

Also you'll need a transaction table, for tracking XA transactions (same as current JBM_TX)

[alesj]

"timfox" wrote:

The JDBCPersistenceManager implementation should use HIbernate (at least the dialects)

Wouldn't straight JPA be better?

btw: what's the main persistence mechanism?

[timfox]

"alesj" wrote:

"timfox" wrote:

The JDBCPersistenceManager implementation should use HIbernate (at least the dialects)

Wouldn't straight JPA be better?

We're not really so interested in using Hibernate/JPA for ORM, more just to abstract out the differences in DML and DDL between different databases.

If JPA can do that too, that's fine. Although I'm not sure we want to pull in a JEE dependency.

btw: what's the main persistence mechanism?

Fast, append only journalling approach.

[bershath27]

"timfox" wrote:
Ok, I have created a JIRA task and assigned to you: http://jira.jboss.org/jira/browse/JBMESSAGING-1172

First thing to do before diving into real code would be to put together wiki page(s) with your proposed design, then we can discuss.

yes. i'm onto it. considering a suitable design pattern to cater our requirement. performance and maintainability are the two things , i'm concerned about
- Tyronne Wickramarathne

[bershath27]

well, i have just a basic design for this, with just three pojo's to do the ORM, one manager and a util class (which contains a static method, which returns EntityManagerFactory )

[img]http://bp3.blogger.com/_tR-4lSus-Z0/R1mPy8ZdRLI/AAAAAAAAADU/m0nxHYlSwrw/s400/JBMPersistence_SimpleDesign.png[/img]

i have simplified this as much a s possible. remember, purposely we have eliminate relationships between entities.

Tyronne Wickramarathne

[timfox]

Tyronne-

This looks like a good approach.

One simple POJO that maps directly to each of the JBM_MSG, JBM_MSG_REF and JBM_TX tables.

Go for it!

[apwalker]

I think the way JBPM manage support for all the different databases is pretty good in that you can generate the DDL from there Hibernate configuration. They maintain a separate DB project where they manage all the different versions of JBPM database schemas.

One common problem that I find working with customers with JBossMQ and JBM is that I often need to provide DBA the DDL for the messaging tables rather than let them get created automatically. So I normally run them into a dev or test environment then you a DB tool to extract the DDL scripts from that. I think it would be better to just run an ant script to generate it from the hibernate/JPA config.

Is the plan you to use the JPA EntityManager or just use JPA to provide the metadata to describe the mapping and then use pure JDBC to access the tables. I have often spoken to the hibernate team about using hibernate/JPA persistence for JBM and the feedback I get from them is it may not be the right fit. I think using Hibernate to provide the DDL for any database is a good idea for managing support for many different databases. If you do go down the route of using JPA/Hibernate I would take a look at using the Hibernate stateless session as it may prove to provide better performance for this type of persistence requirements.

well that's just my two cents for what it's worth...:)

--Aaron

[timfox]

Well the main motivation for using HIbernate is to avoid us having to keep different DDL and DML configs for different databases.

If we can use Hibernate to provide the DML and DDL, and forget the ORM stuff (which we don't need anyway) then that's great.

But I know very little about Hibernate and what it is capable of, so don't know if that is possible.

I should probably get up to speed with Hibernate... :)

[timfox]

Can you give examples/ pointers on how you would use Hibernate to just get the DB specific SQL?

[bershath27]

"timfox" wrote:
Can you give examples/ pointers on how you would use Hibernate to just get the DB specific SQL?

Tim, i'm not suppoed to have/implement any vendor specific SQL. we'll be compromising the main purpose of using HBN/JPA on JBM, which is to abstract different vendor specific DDL and DML stuff. at each different DB implementations, all you have to change is the HBN dialect. nothing more, nothing less. :)

Tyronne Wickramarathne

[timfox]

"bershath27" wrote:

Tim, i'm not suppoed to have/implement any vendor specific SQL. we'll be compromising the main purpose of using HBN/JPA on JBM, which is to abstract different vendor specific DDL and DML stuff. at each different DB implementations, all you have to change is the HBN dialect. nothing more, nothing less. :)

Yes I understand that. I was just trying to make the point that you may be able to miss out the ORM altogether and just use the dialects, and I was asking if you could provide some examples....