Somebody tweeted Distributed transactions in Spring, with and without XA today, and I read it with interest because of my fascination with distributed transactions.

One of the patterns the author left out is how to provide the 2PC-like atomicity for a database and a messaging resource, but without using XA.

This is called “1.5PC” or “one-and-a-half phase commit.”

In a simple application that takes messages from a queue and updates a database, there are four combinations of behavior when things go wrong, two of which are acceptable and two of which are not:

• The message is still on the queue but the database has not been updated, which means the crash happened before the database was updated and the message was removed from the queue. These operations can be safely be reissued. This is considered acceptable.
• The message is no longer on the queue, and the database is updated, which means that both operations completed properly before the crash. This is considered acceptable.
• The message is still on the queue, and the database is updated, a bad scenario that happens when the crash happens after the database is updated but before the message is removed.
• The message is no longer on the queue, and the database hasn’t been updated, a bad scenario which happens when the message is removed from the queue before the database is updated.
  Scenarios 3 and 4 are really the same problem – one resource gets updated, but not the other – and can really be considered one problem, with the order of the resource operations reversed.

  1.5PC requires that the messaging system and the database share a unique identifier. It could be an SequenceID or a TransactionID, but it has to be unique for all time, and the unique identifier does not have to be monotonically increasing (but it helps).

  After a crash, the receiver recovers by looking at the head of the message queue, and using the unique identifier to determine if the message was already applied to the database. If the database updated has been applied, the message can be safely removed from the queue. If it has not been applied, the database is updated with the contents of the message, and the message removed from the queue.

  If you’re using Mule, you can get the same effect declaratively using its Multi-TX feature (although shame on Mule for the registration wall).

  But this is only one half of the equation: it prevents duplicate application of the same message to the database, but it doesn’t prevent the message sender from putting two copies of the same messages on the queue (“dupes”) or failing to put a message on the queue (“gaps”). This can be fixed in the sender with similar coordination between the source database and the message queuing system, which is left as an exercise for the reader.

  (Thanks to @RossMason of MuleSoft for providing feedback on an earlier version of this post.)

Most of us who work in the technology business don’t have to read GigaOM to know that seed and angel funding is very much in vogue.

But what is less obvious, but borne out by a report from CB Insights, is that most of the seed funding is in Internet startups, like social media, content, ecommerce, and applications (both consumer and enterprise).

This shouldn’t be much of a surprise because most angel investors concentrate on consumer internet startups.

But where does an entrepreneur look for angel funding for storage and data management, security, networking, high-performance computing, cloud computing, grid computing, parallel processing, transaction processing and application servers, messaging and event processing, mobile infrastructure, security, etc?

How is your angel investor going add value if he doesn’t completely understand the product or the market?

Or if he doesn’t have the right relationships at Citrix, Oracle, SAP, Intel, IBM, BMC, Cisco, RedHat, VMWare, etc.?

That’s why you need someone like me, who has the technical chops, the operational experience, the rolodex, and the alpha-geek mentality to help you get your core technology or infrastructure startup to the next step.

Write: seed –at– “my last name” –dot– net

Deal syndication in angel and seed investing is a double-edge sword for the entrepreneur.

On positive side, you get a bunch of smart and well connected people and firms investing, who will all work individually and in concert to help you out.

On the other hand, with this arrangement you may miss the opportunity to get the best price for you deal because the “lead” angel sets the price, and other investors get to ride along.

The question is whether syndicate investors might have paid more if you had talked to them first, and your lead would have been a follower at a higher price.

In deals where the entrepreneur is having trouble filling the round, there’s not much choice, and the “rolling capital raise” works in the entrepreneur’s favor. He takes what he can get as it comes along, and moves on.

But in deals that are over-subscribed, a more entrepreneur-friendly solution would be to allow more capital in, and increase the pre-money valuation proportionately. This way, increased interest in the round will increase the price of the round.

Recently, Marc Hedlund, the founder of Wesabe, ruminated on Why Wesabe Lost to Mint.

I feel somewhat qualified to comment on this topic because I did the technical diligence on Mint for First Round Capital, which led me to become an investor in the company. Furthermore, I have been a business acquaintance of Marc’s for over 10 years.

Marc’s answer to this question revolves around two criteria for success: (1) “making users happy quickly” and (2) “actually helping people” with their finances, and that “Mint totally won at the first…and we both totally failed at the second.”

Both of these points are correct, but I’d like to make some additional comments.

First, I think that by focusing on Yodlee’s impact on Mint’s out-of-the-box experience, Marc underestimates the other benefits of Mint’s decision to use Yodlee. There are almost as many banking APIs as there are banks, and Yodlee’s product supports over 10,000 data sources, and over 100,000 different account types. That’s almost a “boil the ocean” problem. When I spoke with Aaron Patzer back in 2007, I had the same doubts about Yodlee that Marc expressed, and Aaron’s answer was something along the lines of, “Well, if it works, it eliminates a tremendous amount of work for us. If it doesn’t work or if they screw us, we’ll rip it out and do something else.” They key principal for “build versus buy” decisions is “buy for parity, build for advantage,” and (as Marc freely admits) Mint made the right choice. Wesabe should have spent the money and engineering resources on building its unique value.

The second key point from my perspective is based on the impression that Aaron made on me during our first discussion. In the past 10 years I have seen over a thousand pitches and have meet thousands of entrepreneurs. Aaron Patzer is in the top 5 entrepreneurs I have ever met, and certainly the youngest. Mint also holds the distinction of being the only company where I didn’t know the founders, yet pulled out my virtual checkbook immediately after the first meeting. [In all fairness to Marc, he has never pitched me. I tried very hard to hire him once (and would again), and it was a fairly big loss that he turned us down. And given the opportunity, I would likely pull out my checkbook for him, too.]

My last comment is about the question Marc asks in his title: “Why Wesabe Lost to Mint.” The personal finance market, unlike, say, social networking, has no network effect, nor is the market a zero-sum game. We should have seen multiple exits in “web 2.0 personal finance,” like we did in the Java Application Server space. I think the real question Marc should be asking himself is “Why did Wesabe Shut Down instead of having an exit?”