Slashdot Mirror

The commercial solution is called Tuxedo

Can you comment on possibilities for developments relating to transaction processing and database management systems?

"For instances" to make this clearer include:

• RHAT has apparently been putting work into the availability of raw partitions that the major DBMS vendors prefer to the use of native filesystems.

  Ala SCT-RAW , raw i/o patches

• TP monitors such as BEA Tuxedo as well as message queueing systems such as IBM MQSeries.

  There's one "libre" option, Isect

• It'll not be scalable enough.

  For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.

• It'll not be robust enough.

  Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).

• It'll not integrate well enough with whatever tools they're using next year.

None of the technologies are inherently a problem:

• SOAP doesn't seem to be massively worse than XML-RPC although it's probably not as good as Casbah's LDO system.
• MTS is probably not as good as Encina or Tuxedo, but is doubtless better than the nonexistent TP monitors not being deployed in departmental/workgroup systems
• MSMQ may not be as good as Tuxedo, or as open as Isect, and is merely derivative of IBM MQSeries, but doesn't seem to be too bad, again being better than the asynchronous messaging systems nonexistent in non-big-iron systems

The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.

What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.

In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3, ... and this results in the tools deployed having an extra year to stay vaguely stable...

Yeah, it's probably not good karma to look like an idiot in one post, and then answer your own damn question in the next, but I found weblogic, and it was FAR too easy to find at weblogic.com, which redirected me over to beasys.com...

Anyway, if anyone else wants More info on weblogic, there it is.

Yeah, it's probably not good karma to look like an idiot in one post, and then answer your own damn question in the next, but I found weblogic, and it was FAR too easy to find at weblogic.com, which redirected me over to beasys.com...

Anyway, if anyone else wants More info on weblogic, there it is.

• The situation with Solid displays nicely that the use of non-free software provides exposure to the risk that a vendor will decide to "Change their Business Strategy."

  If Solid decides to move from selling licenses at $300 targeted at web servers to selling $10000 licenses targetted at use in embedded systems (speaking loosely of "embedded," of course), there is little that the customer can do.

  If IBM decides not to provide an upgrade next year for Linux, and push users over to running DB/2 on Monterrey, there may be little that the customer can do.

• On the other hand, there are some tasks such as writing documentation and building test suites to verify compliance with standards that aren't "sexy" tasks and which thus have a tendancy to suffer on "free" DB platforms.

I suppose the given is that there are some significant risks regardless of the approach you take.

The observation that code should be written to be, as much as possible, independent of the DB engine, is certainly true. This diminishes the extent to which you're locked in.

This is valuable whether we're talking about Oracle or MySQL.

Related to this, it seems to me that people should be looking into using transactioning/messaging "proxies" like BEA Tuxedo (proprietary) or less proprietary things like the Isect message queuing system.

I think that I see your problem. I had assumed that you were working with applets and that's why you were complaining about speed. In reality, its probably just your expectations.

In an NT world you are using at least 32 MB just for the operating system. Add another 16 for application server overhead, and another 16MB for web server overhead and caching, and that means that you are going to be paging to disk constantly even with low system usage. Assuming ten thousand concurrent users, you have just 6.4 KB per user, not even counting the overhead.

Yes, an Apache/mod_perl system will run better under these kinds of conditions. Linux has a much leaner footprint, and Apache can be tweaked for low memory footprints.

On the other hand, if you are going to be paying six figures for application server software (Tengah, now called WebLogic after being bought out by BEA, isn't cheap) why don't you invest some money in hardware? Most application servers require at least 128MB per processor and most recommend a quarter gig to a half gig per processor. (Application servers tend to be much more memory intensive than CPU intensive. I've even seen some systems perform much better with 1GB per processor.) You can get 128MB SIMMS for $300-$400 these days.

The bottom line being: if you have an existing low-end piece of hardware that you need to get the most bang for your buck from, you should be looking at PHP or something similar. If you are looking for something that is scalable to tens of thousands of concurrent users, and is easy to develop and maintain, you should be looking at Java application servers. But if you do, you should expect to have to scale your hardware appropriately.

Their product is really very nice, but a little expensive (like $10K). If you're doing enterprise Java work, it's great though. It supports (or plans to support in the near future) all the "enterprise" java APIs and services.

-nate