... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)


BEA Aqualogic DSP

I tried to do a federated update using Aqualogic DSP.  I got this error message:

java.rmi.RemoteException: EJB Exception: ; nested exception is: com.bea.ld.dsmediator.DataServiceException: java.sql.SQLException: Connection has already been created in this tx context for pool named inventoryMM. Illegal attempt to create connection from another pool: inventoryDev2

This issue appears to be that the JDBC driver that I was using is not XA compliant.  I tried switching to the XA version of the BEA MS SQL Server JDBC driver, but it required changes to the underlying SQL Servers to function correctly.  So I tried the jTDS XA driver instead, in 'XA emulation' mode where it pretends to participate in XA transactions, but doesn't.  That didn't work -- I got the error message:

Error obtaining database connection 'inventoryDev1': SQL operations are not allowed with no global transaction by default for XA drivers. If the XA driver supports performing SQL operations with no global transaction, explicitly allow it by setting "SupportsLocalTransaction" JDBC connection pool property to true. In this case, also remember to complete the local transaction before using the connection again for global transaction, else a XAER_OUTSIDE XAException may result. To complete a local transaction, you can either set auto commit to true or call Connection.commit() or Connection.rollback().

I tried the 'supportsLocalTransaction' suggestion, but then I got another error message (which I forgot to write down).  [After trying the steps that follow, I wonder whether it all would have worked if I had just restarted the servers in the right order...]

I decided to bite the bullet and use BEA's XA drivers.  The first step is to install a DLL and some stored procedures in each server, following the instructions in Installing Stored Procedures for JTA from the WebLogic JDBC driver manual.  I then created drivers for three machines.  Two were Windows 2003 Server boxes and the connection pools came up right away.  However, the third machine was my XP workstation, and when I tried to test the connection pool, I got a message saying the SQL Server was unable to contact the DTC service.  I tried to start the service, but I still got the error message:

java.sql.SQLException: [BEA][SQLServer JDBC Driver][SQLServer]xa_open (0) returns -3

After much fiddling about, I discovered that I had to restart all the relevant services after making changes.

I tried to run some data service functions in WebLogic Workshop, but once again I got the "no global transaction" error.  So once again I tried setting the 'supportsLocalTransaction' option, but this time the data service worked... as did a single-source read through the SDO client, and a single-source write, and a multi-source write (which was the problem to be solved).

  So, the winning formula was:

  1. Install the required DLL and stored procedures in SQL Server (Installing Stored Procedures for JTA).
  2. Start the DTC service.
  3. Use Component Services administrative tool to enable remote logins and XA transactions in the DTC service, and to start the service.
  4. Restart SQL Server.
  5. Start the WebLogic server.
  6. Create the connection pool in WebLogic using the BEA XA SQL Server driver.
  7. Set the 'support local transactions' option on the pool.
  8. Repeat steps 6 and 7 as many times as needed.

A posting on the BEA JDBC newsgroup was helpful, SQLException when creating XA connection pool.



I noticed that the TortoiseSVN process TSVNCache was growing by 4K every few seconds.  At times, it was also consuming 50% of the CPU.  Since my machine was acting sluggish from time-to-time, I suspected that TSVNCache might be the problem.  The TortoiseSVN mailing list was full of people discussing/complaining about the performance of the cache feature.  The general consensus was that while the caching thread was running with 'idle' priority, it was performing a large number of uninterruptible I/Os.  The net result was that the process was too resource intensive.  The solution is to turn of 'recursive processing' in the TortoiseSVN settings.  Note that this setting was removed from early versions of TSVN 1.2, only to be re-introduced in later versions as a result of this issue.  TSVN 1.2.6 has the setting.  See http://svn.haxx.se/tsvn/archive-2005-05/1219.shtml.



BEA Aqualogic has difficulty with database objects with non-standard SQL names.  For example, when I tried to import metadata from a table with a dash in its name, none of the table's columns were retrieved.  No errors were reported, neither in the Workshop UI nor in the various log files.  I traced the SQL and noticed that Aqualogic was not escaping any of the SQL identifiers.

If you execute an ad hoc query using DataServiceFactory.prepareExpression(), you must return a single element as the result.  If you return...

  • ... an atomic type, the error is "Unexpected element: CDATA"
  • ... multiple elements, the error is "Unexpected element: OPEN_TAG"
  • ... zero elements, the error is "Unexpected end of file after null"



I was looking at Maven again today.  Version 2.0 looks quite impressive.  The features that caught my eye were the dependency management and the automatic Eclipse project generation function.  Lots of useful information can be found in the Maven Blogs.  Also of interest are the Maven SCM plug-ins, and a continuous build server from the Maven team called Continuum.

BEA Aqualogic

Using the BEA Aqualogic Data Services Platform, Workshop version 8.1.4, I had trouble building the SDO mediator client JAR.  The problem was that none of my changes were making it into the client JAR.  I discovered that you must manually rebuild the application EAR file first -- rebuilding the application alone is not enough.  Apparently, Workshop never rebuilds the EAR file automatically -- at least I haven't found a way to do so.  The 'clean application' command does not delete the EAR file.  Note it doesn't matter whether or not the WebLogic server is running during any of these activities.

As an aside, I cannot find any way at all to delete an imported relational data service.  I had imported a table called 'well'.  I manually deleted the DS file, and rebuilt the application.  It was unable to compile another data service that referenced 'well' as a relationship.  I manually deleted the relationship function, and then the application built completely.  However... when I created the client JAR, 'well' was still there.  I can't find any reference to it anywhere, so I'm not sure why it is still turning up.


Maven interacts with ibiblio, self-styled as "the public's library and digital archive".


JUnit Fixture Setup

suite() method as follows:

    public static Test suite()
        return new TestSetup(new TestSuite(ThisClass.class)) {
            protected void setUp() { setUpFixture(); };
            protected void tearDown() { tearDownFixture(); };

It doesn't work properly in Eclipse, however, if you try to run a single test method -- the fixture set-up and tear-down are not run.  SingleSetupTestSuite defined in my SQL testhelpers library does not suffer from this problem (perhaps I should make a general version of that class some day).

Blog Archive