Allan Saddi's projects blog - Java

TranQL Connector for PostgreSQL

nospam@example.com (Allan Saddi) — Mon, 11 Jun 2007 09:39:28 -0700

As far as Java development goes, for personal projects and for work, I find myself in that odd place between needing only a servlet container (e.g. Tomcat) and needing a full JEE container. I'm sure this situation is quite common. The one thing that I almost always end up needing beyond plain servlets is JTA. As I've mentioned in the past, I've tried various solutions from plugging in JOTM, which I'm not at all too happy with, to using stripped-down versions of full application servers.

Well, the problem for me is still unresolved, but I did try out Jencks over the weekend. It was fairly easy to set up, and it worked as expected. (Just have to remember to set the connection manager's transaction type to XA to actually get XA transactions!) And rather than using DataSourceMCF, one would probably want to use a real MCF for your database for XA functionality.

Which brings me to the point of this post. In the past I've blogged about problems with PostgreSQL/XA/TranQL (here and here). Although the problem was resolved in the driver long ago, I don't believe I ever published the actual PostgreSQL TranQL connector I made. (And believe me, I would rather fold it back into the original project... but I'm having a hard time finding contact information... or a working mailing list... anything.)

Anyway, the connectors: http://maven.saddi.com/org/tranql/

I've tested it with Jencks and Geronimo. (And by "test", I mean I just verified that the PostgreSQL driver is indeed using 2PC.) The source can still be found in the same place: http://www.saddi.com/software/tranql/. You'll probably need to use the latest 8.2 JDBC driver (which includes the above-mentioned fix).

Hopefully anyone searching for TranQL/PostgreSQL will eventually stumble upon it. I mean, I can't be the only person interested in using XA transactions with PostgreSQL in Geronimo, right???

Tapestry: A return to the familiar?

nospam@example.com (Allan Saddi) — Wed, 08 Nov 2006 09:00:15 -0800

I often heard about the Tapestry framework in passing, but I never really paid heed to it. It wasn't until I read a minor blurb about it in Rod Johnson's J2EE Development without EJB that my interest was finally piqued. Basically, it stated that Tapestry was inspired by the WebObjects' Page/Component model, something I am somewhat familiar with. Something I look back at with a certain nostalgia.

WebObjects was my first experience with a "real" web application framework. Before then, I was working with CGIs and my own cobbled-together Python modules. After proving to myself that I could indeed run it on my collocated FreeBSD server (an unsupported platform by WebObjects... not to mention by Java as well, back then), I started dabbling in Enterprise Objects/WebObjects. Eventually, I wrote a number of applications, though mostly internal.

It also gave me a chance to brush up/re-learn Java. Though WebObjects was heavily tied to the OpenStep way of doing things, just under Java (i.e. the collections were not standard Java Collections, among other things), which I didn't really like.

Anyhow, I moved on from WebObjects, preferring to do my Java web development with "frameworks" like Hibernate and Spring. But WebObjects had some neat ideas, and anything WO-inspired will always catch my attention. (For example, in Python world, there's the Modeling framework, which looks promising.)

Anyway, no where in the Tapestry site will you actually see the word WebObjects, which is probably why I glanced over it before. But having played with Tapestry now, I see the influence. And not only that, with annotations and automatic state management, Tapestry has taken the Page/Component model to another level. (And the upcoming Tapestry 5 looks even more exciting.)

But, the thing that made WebObjects development bearable was WOBuilder, the graphical, WYSIWIG page/component editor. I haven't looked at the IDE plugins for Tapestry yet, but that level of integration seems to be missing. (Editing a page/component involved editing 3 files — the class, the spec, and the html template. WOBuilder actually edited all 3 in a relatively sane manner.)

I'll probably play with Tapestry a bit more, and I've already built a template web applications for myself. Whether or not there's a decent Tapestry plugin for Eclipse will probably decide whether I'll base any future projects on it. Though you can omit the spec file using annotations in the Java class, editing the template files by hand seems a bit daunting. In fact, it reminds me, not so fondly, of my homebrew Python templating engine, HTMLpp.

Though Tapestry 5 templates seem a lot easier to write...

Continuing adventures in...

nospam@example.com (Allan Saddi) — Sat, 07 Oct 2006 08:52:11 -0700

After reading the JTA/J2EE Connector specs, I've decided the problem is indeed in the PostgreSQL JDBC driver. It sets autocommit to false and assumes it remains false indefinitely. tranql is (correctly) re-enabling autocommit in its ManagedConnection.cleanup method.

So I patched up PGXAConnection so its autocommit handling is a bit more sane... i.e. it's on by default and is only turned off within XA transactions. Outside of XA transactions, it's re-enabled.

Anyway, quite an educational experience... I now know a little more about JTA/XA/resource connectors. More than I really wanted to, actually.

I'll have to clean up my patch (and re-do it against HEAD), but it's available here along with a re-compiled jar.

Here's a bug/email about the problem brought up a few months ago. I don't think anything was ever done.

Now hopefully I can move on to actually writing apps...

Adventures in JTA

nospam@example.com (Allan Saddi) — Fri, 06 Oct 2006 12:57:29 -0700

I decided to (temporarily) convert my skeleton webapp to use JTA. Being Spring-based, it was a simple matter of editing the application context config... or so I thought. Apparently, for distributed transaction support, it has to be supported by not only the application and container, but also the connector and database driver.

Doing some research, I found out I needed an XA compliant connector... which are apparently vendor-specific. I searched tranql's site and surprisingly, there is no PostgreSQL support. "Why is this?" I asked and the answer (through Googling) turned out to be because PostgreSQL itself doesn't have XA Resource support... let alone two phase commit.

Or so I thought. All the various blogs/articles stating the fact were apparently out of date. PostgreSQL has had 2PC support for over a year. And the JDBC driver has also supported XA for some time.

So great... I just needed a PostgreSQL-specific tranql connector. (Again, very odd that one doesn't already exist.) After a minor struggle searching for tranql's source (note that the CVS info at their site is outdated... I used Codehaus' FishEye repository browser instead), I managed to see what was involved in creating a vendor-specific connector.

Very little, it seemed. So using the Derby connector as a starting point, I went ahead and created PostgreSQL tranql connectors, in both local and XA flavors. It was so utterly simple, I don't know why it wasn't done before. (And I've googled around...) I don't know if I should even bother contributing it back? It was literally a matter of changing a few package/class names and deleting some unused setters/getters...

Anyhow, the tranql connectors for PostgreSQL can be found here for now. You'll need to use a PostgreSQL JDBC driver that supports XA (like 8.1-407).

As far as I know, it works (but that doesn't really say much). Someday I'll have to create a simple app that uses two or more datasources and play around with it more.

Edit: Maybe I spoke too soon. For whatever reason, rollbacks are still committing. The XA connector looks to be written ok, and after enabling debug logging, I see rollback being called on the XAResource... so maybe it's a driver problem?

Edit2: Found it. Looks like tranql commits by calling setAutoCommit(true). The connection then becomes stuck with autoCommit on. (Which is odd, since beginning a transaction sets it to false... maybe the Geronimo transaction manager doesn't normally do a begin?) I fixed it by patching the PostgreSQL driver, namely the XAConnection implementation. Seemed the cleanest approach for now. Will have to investigate the begin issue another time...

On Containers...

nospam@example.com (Allan Saddi) — Fri, 22 Sep 2006 12:09:34 -0700

All this time, I've been running my Java web applications on plain Tomcat... with a few jars thrown in. And I've been pretty happy. The only J2EE (or JEE?) thing I needed that Tomcat didn't provide out of the box was JavaMail support. (I'm trying to stay away from EJBs...)

Then I started thinking... it would be pretty nice to be able to update two or more databases in some future app I write. (For example, a global "user" database and an app-specific database.) So logically, of course, this brought me to JTA. I searched for free JTA implementations and found JOTM, which seemed to meet my needs well. It even had documentation on how to integrate it with Tomcat. But unfortunately, the docs were quite outdated and I had no luck.

I was about to give up when I stumbled upon this and subsequently this. It was exactly what I needed... documentation on integrating JOTM with Tomcat 5.5.x running on Java 5. Aside from a minor shutdown problem (i.e. it didn't), it seemed to work nicely.

But the fact I had to cobble it together made me wary. (Not to mention JOTM hasn't been updated for a while and the mailing list seems a bit... dead.) So I started thinking along the lines of... what if I took a full J2EE container and stripped it down?

So for the last week or so, I've been playing with various (free) J2EE containers. I've tried out Geronimo, JOnAS, JBoss AS. (This is hardly an exhaustive list, of course.) J2EE containers, I've learned, are rather large, almost-unwieldly beasts. Sure, my new server has 2GB of RAM, but I didn't want most of that to be taken up by an appserver. Anyhow, for technical, ideological, and ease-of-use reasons, I decided to go ahead with Geronimo.

Geronimo comes in two flavors: a full J2EE-certified container and a minimal installation ("Little-G"). After some playing around, it turns out what I needed was actually something in between. First I tried starting with the full thing and shutting down services I didn't need. It worked pretty well... aside from the fact that I needed axis-deployer to be running to successfully deploy war files. (Despite having turned off axis itself...)

So I tried the other way: started with Little-G and copied things from the full version. And that, it seems, is the better approach. (It gets around the axis-deployer problem by having a stub called unavailable-webservices-deployer... imagine that! ) Anyhow, for future reference, what I ended up copying to Little-G was:

repository/tranql/tranql-connector
repository/geronimo/geronimo-mail
repository/geronimo/geronimo-javamail-transport
repository/geronimo/javamail

And I also threw in the hot-deployer module and jar file because it's such a convenient way to deploy apps. The tranql module is needed to be able to deploy DB connection pools (odd that it isn't included in Little-G, huh?) and the rest are for JavaMail support.

Anyway, I moved all but one app to this new set up. (The holdout is Roller... no matter what I did, it just wouldn't work. Not insurmountable, but seemingly just some annoying classloader problem I have to work out...)

Anyhow, after going through all that, I feel a bit compelled to write something that requires JTA now...

Java implementation of Advogato's trust metric

nospam@example.com (Allan Saddi) — Fri, 02 Jun 2006 16:22:27 -0700

I thought I'd go ahead and release my Java implementation of Advogato's trust metric. I thought it was a relatively clean (IMHO) interface-based design and I just wanted to share.

Note that I haven't actually used it anywhere though. (I plan to use it in Flup, the website.) And the unit tests are laughable. But as far as I can tell, it works as expected. (The flow network and actual trust metric code are based off old Python implementations...)