I have just commited the latest update to my store code. The JDBC3 and PostgreSQL module play nice the JBoss Client Transaction Manager now. Currently it has similar behaviour to the EJB "Required" transaction type, mainly because the Client Transaction Manager doesn't support nested transactions. (Given the transaction requirements for these 2 modules perhaps they should be EJBs....) The BDB module is also there and works, but from what I have garnered from the sleepycat mailing list, it looks like BDB doesn't actually support partial reads/writes, so I may have to deprecate this module in the near future.
I have retested with the latest MySQL JDBC Connector (3.1.7 final), and I am going eat my words now. It is a lot better. The MySQL bug 8096 is now fixed and performance is much improved (Bug 7745 will still cause problems http://bugs.mysql.com/bug.php?id=7745). The main question for now is where do we go from here. We have 2 different implemenations covering the same area. The decision is how we merge the 2 and produce something useful. Below is my take on it (I could be wrong, and I am quite willing to do something complete different if it is the better approach). Partial read/write support. This IMO is the most important feature of Message Store. Without this we are better off simply holding the message in memory. Where does that leave the Hibernate implemenation, which doesn't support streamable blobs. An option is still use hibernate ORM features, but build an object model that supports the partial read/write requirement. This could be done making the StoredMessage object aggregate a number of StoredPage objects of a fixed maximum size. On top of this model we would need Paged[Input/Output]Stream which would fetch or flush a page whenever the current page is underrun or overrun respectively. This would provide a simple generic implementation that would be usable across multiple databases. User defined meta data. This is information such as sender address. Currently the store implemation doesn't support this, but can be if required. For starters a simple string will suffice, but eventually name/value pair style properties would be preferred. Where does it sit (AKA what's in a name). When I wrote the current store implementation I didn't want to tie any particular domain. I.e. I avoided the use of terms such Mail and Message. It was designed as a store for any type of big thing that we may want to stuff in it (e.g. Calendar appointments with attachments). Is this something that is important? If so then the hibernate based implemenation should be moved to org.jboss.mail.store. If it should be specifically a message store then the reverse should happen. The store interface. Currently neither of the 2 implementations have an interface that covers all the bases. Who specs it and what it is based on will be largely decided by the outcome of the above paragraph. Just something that needs to be done 'tis all. One specific on the interface is that we need to support different store implementations, which will use different data types for their ids. This suggests the type of the id needs to be an Object or a Serializable rather than a String. This is what needs to be tied up before seriously integrating it into the main execution path. I am happy to do any, all or none of the above. I didn't want to go stomping all over others peoples code and making decisions without fostering a little discussion first. Regards, Mike View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3868965#3868965 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3868965 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
