WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Thanks for being willing to throw those snapshots up into the maven
repository. Though we ended up working up another way to get the code
in. Unfortunately, it didn't resolve the enlistment error we are seeing
so we are continuing to look for causes of the problem.
Ludovic Orban wrote:
> It definitely is a good idea to upload the BTM-2.2 artifacts into the
> codehaus snapshot repository.
> You should have enough privileges to perform the upload, just edit (or
> create) $HOME/.m2/settings.xml and add a server element in it with your
> codehaus credentials:
> <settings xmlns="http://maven.apache.org/POM/4.0.0"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/settings-1.0.0.xsd">
> After that, you should be able to invoke 'mvn deploy' which will upload
> the artifacts at the right place.
> 2011/12/12 Brett Wooldridge <brett.wooldridge@... > <mailto:brett.wooldridge@...>>
> Hi Eric,
> The BTM-2.2 snapshots are not currently being published to the
> repository. To be honest, I don't know how to make that happen.
> Ludovic is the project owner/lead and would need to make the call
> on whether he wants to put BTM-2.2 out there. Most of the changes
> in BTM-2.2 are cosmetic in nature (converting untyped collections to
> Java 5 typed collections), but there are a few fundamental changes
> around JDBC4 handling and synchronization (increased concurrency).
> Recently Ludovic has had limited time to review incoming changes,
> and may not have enough of a comfort level to put BTM-2.2 out there.
> Having put a lot of time into BTM-2.2, I am obviously biased toward
> wanting to get it out there so that it can be tested by adventurous
> developers. As with any refactor that includes threading changes,
> the best way to get a comfort level is through having it run in
> various environments by users -- because obviously we can't
> desk-test such a large number of databases and development stacks.
> As I said, I've been running BTM-2.2 in my company's own
> pre-production environment under load with high-thread counts and
> transaction volumes without issue. We'll see what Ludovic things
> about putting BTM-2.2 into the snapshot maven repository.
> On Mon, Dec 12, 2011 at 6:13 AM, Eric Westfall <ewestfal@... > <mailto:ewestfal@...>> wrote:
> Thanks Brett, OJB does have it's own connection pooling support
> built in, but we are not actually using that the way we have it
> configured. One question about your development version of
> Bitronix (2.2). You don't happen to have that available as a
> snapshot in a maven repository somewhere do you? We use maven
> on the project so that tends to make it easier for us if we can
> just change our dependency version ;)
> Right now, we're checking to see if we are getting connections
> bound across threads to the Spring Framework's
> TransactionSynchronizationMana__ger which is a problem we have
> had before in the past (though for reasons we aren't entirely
> sure of).
> Brett Wooldridge wrote:
> Hi Eric,
> That's interesting that you say that. I'm reluctant to
> point the finger at a third-party's code but to tell
> truth, after your initial post, I started looking at:
> The ConnectionManagerImpl immediately raised a flag in my
> mind, as it appeared to be either pooling
> it's own connections or trying to maintain some kind of
> connection-to-local-tx mapping. Something
> like that inherently won't mix well with many JTA.
> You may still able about to use Bitronix, but you might try
> turning off shareTransactionConnections
> in Bitronix. You might also investigate the "eager-release"
> configuration setting in the apache orb
> configuration. Search for "eager-release" here:
> http://db.apache.org/ojb/docu/__getting-started.html#Sample+__project-N104AF > <http://db.apache.org/ojb/docu/getting-started.html#Sample+project-N104AF>
> <http://db.apache.org/ojb/__docu/getting-started.html#__Sample+project-N104AF > <http://db.apache.org/ojb/docu/getting-started.html#Sample+project-N104AF>>
> We'll be interested in what you find out.
> On Sun, Dec 11, 2011 at 3:59 PM, Eric Westfall
> <ewestfal@... <mailto:ewestfal@...>
> <mailto:ewestfal@... <mailto:ewestfal@...>>>
> Hi Brett, thanks for following up. I think after some
> I'm leaning toward this being an application issue and
> not something
> inherently wrong in Bitronix. I wrote a simple little
> test and
> verified that this error happens whenever a
> gets reused across multiple concurrent transactions in
> threads. So I think there is probably something going
> wrong "above"
> the tm/pooling layer.
> The application is using Spring (version 2.0.8, so it's
> pretty old)
> as well as an old ORM from apache called OJB. I suspect
> right now
> that a bug in one of these layers is causing the
> of connections.
> If I do think there might still be something going on in
> here, I will definitely be willing and able to try out
> that new
> version and let you know if it fixes the problem.
> To unsubscribe from this list, please visit:
> http://xircles.codehaus.org/__manage_email > <http://xircles.codehaus.org/manage_email>
To unsubscribe from this list, please visit: