Atomikos Forum

I'm a chief developer of HyperSQL database.  I would like to use Essentials to test our rewritten ConnectionPoolDataSource and XADataSource implementations; and to use Essentials and Extreme in our examples for pooling and XA usage.

There is a demand for pooling-only usage as well as XA usage.  The existence of several pooling-only connection pool managers is evidence for this.  I very much would like to use a single product for both pooling and XA data source management, instead of a different product for each use case.  XAConnectionFactory should work just great for my XADataSource, but it looks like all of the *NonXA* classes are intended to wrap XA transaction capability around the supplied non-XA data source.  Is there no way to use Atomikos without XA capability?

Hi,

Our current pools should also work without a JTA transaction context for the calling thread, in which case there will be no XA done either. However, you would still need to use the XADataSource at the JDBC end. Does that help?

We thought about offering non-XA pools also, but did not do this because there are enough good pools around. Are you suggesting that we change the strategy and put this on our roadmap?

Thanks

No, that doesn't help, as I can't test the HyperSQL ConnectionPoolDataSource with Essentials if Essentials will never use it.

If you haven't had demand for integrated ConnectionPool + XA support, then I guess the users are disparate groups.  I happen to need to test and support both and I'd prefer not to have to learn all the details of, become an expert with, and help users with, two different products, considering large amount of overlap.  You have obviously implemented connection pooling functionality so I thought you would throw some hooks in for ConnectionPoolDataSource.  Nothing wrong with concentrating on your unique strengths though (transactions and XA).

I'll suck it up and try c3p0 for XA-less pooling and Atomikos products for XA.  While there are many connection pool connection managers out there, c3p0 is the only open source one I've found that is active and which supports javax.sql ConnectionPoolDataSources.  I was quite disappointed to see that Apache's dbcp makes no attempt at generic support of the javax.sql spec.

Sorry to self-reply, but based on what I have learned in the interim, it looks like you would be unique in providing proper support for javax.swing.ConnectionPoolDataSource.  It seems that even c3p0 does not support it to the level needed for easy integration with container managers.  From c3p0 documentation:

    many c3p0-specific properties are unsupported with third party implementations of ConnectionPoolDataSource.

It's looking like we'll (HyperSQL team) have to write and maintain our own connection pool manager for pooled-only.  If I were to build this capability on top of TE, could I get tips here (understanding that this is for an open source database), and would you recommend this as practical for a senior Java developer who has writen ConnectionPoolDataSources and connection managers before?

Hi,

What do you mean with javax.swing.ConnectionPoolDataSource? We only implement javax.sql.ConnectionPoolDataSource in our older JDBC classes - if there is a need for it in the newer ones we can gladly add that too, BTW. Can you explain why it is important to you?

In general, regarding to non-xa connection pooling I can try to help to the extent possible (mostly restricted by lack of time;-).

Another option would be to explore what is needed in our code base to add non-xa pooling. Maybe we can try that first? If it turns out to be minimal then who knows. Care to help out?

Best

Re: Guy

I see no indication that this forum supports wikitext or such, so, without spending time searching, I'll just prefix my inline replies with "**".

Hi,

What do you mean with javax.swing.ConnectionPoolDataSource

** Mistake.  Boisterous neurons who should have been working other unrelated problems temporarily took over my typing fingers.

We only implement javax.sql.ConnectionPoolDataSource in our older JDBC classes - if there is a need for it in the newer ones we can gladly add that too, BTW. Can you explain why it is important to you?

** I have, in this thread.  I am a team developer for HyperSQL database, the most used pure Java database in the world.  We have newly re-written ConnectionPoolDataSource and XADataSource implementations.  I would like to use TE for manual and automated testing of them, and as we get many questions about how to integrate HyperSQL with frameworks, I'd like to be able to recommend and provide samples using a single bridge product that satisfies all needs (most importantly, both users who want to use our ConnectionPoolDataSource and those who want to use our XADataSource). 

In general, regarding to non-xa connection pooling I can try to help to the extent possible (mostly restricted by lack of time;-).

Another option would be to explore what is needed in our code base to add non-xa pooling. Maybe we can try that first? If it turns out to be minimal then who knows. Care to help out?

** Yes.  If it will be several days before you can "explore", then please email me any tips you may have, like narrowing down relevant classes, so my own exploration will be more efficient.

** Thanks

Best

Blaine,

Thanks. At first glance, at least the pool itself seems generic enough for non-xa usage. See package com.atomikos.datasource.pool:

The JDBC and JMS connectors extend this by implementing the  ConnectionFactory, XPooledConnection and ConnectionProperties interfaces.

Also see the design of our pools as outlined here: http://www.atomikos.com/Documentation/TransactionsEssentialsArchitecture - you can find some inspiration there.

Let me know how you would like to proceed - I can setup a dedicated repository if you like; we can experiment there and see what gives?

HTH

Typo in my last post: ConnectionProperties -> ConnectionPoolProperties

Sounds good.  I'll study the classes and doc that you have recommended, then get back.

Many of the essential classes under discussion (both discussed in the archit. docs and the package and classes you've pointed me to) are not in your Javadocs.  Do they have package visibility or something?  If you don't have a more inclusive JavaDoc build, I'll build some myself, turning up coverage if necessary.  Just lemme know pls.

I'm hoping that I'll have time tomorrow night to write some sample apps tomorrow to play with Atomikos and the pooling some.

That is becuse javdocs were done only for end user classes. However, our newer builds with maven will have more coverage. Starting from release 3.7 on...

HTH

When you deprecate a class and want people to use the superseding class, it's best to not hide the superseding class.  If you don't provide a @see or link, at least type in the class name.

JavaDoc for com.atomikos.jdbc.ConnectionPool:
As of release 3.3, the newer pool should be used instead.

What is the new class?  That JavaDoc collection documents no other class named as a general pool.

I am working on this.  I ran a test without a JTA transaction in scope, and that turned up a possible design problem at our ConnectionPooolDataSource/PooledConnection level, that I need to take up with the HyperSQL project lead.  It will probably take some days of communication before I get that straightened out and return here.

I found the new PooledConnection class and all the rest.  Makes much more sense with source code and full JavaDocs on hand.

BTW, the source code does not match the binaries in the current TE distribution.  The line numbers in stacks are wrong, showing that somebody modified code between compilation and zipping, unless you use some pre-compilation magic or something.  Most likely a bad or circumvented CM build process.

Hi,

Thanks for the feedback. All of the annoyances you mention are solved with our maven build :-)

Cheers