We've know it for a while, but this in­de­pen­dent blog post con­firms the facts: lin­ear scal­a­bil­i­ty.

Due to a serv­er mi­gra­tion you may ex­pe­ri­enc­ing prob­lems with sup­port emails. We are work­ing to re­solve the prob­lem.

In the mean­time, thanks for your un­der­stand­ing and pa­tience.

Check out this news post to learn more about DataNu­cle­us and the de­tails of this news item...

Best wish­es for the new year to all of you, from all of us!

Cheers

We are ask­ing for com­mu­ni­ty in­put on the fol­low­ing: over time, our ini­tial­iza­tion mech­a­nism (prop­er­ty file, sys­tem prop­er­ties, prop­er­ties sup­plied pro­gram­mat­i­cal­ly) has been pol­lut­ed a bit and as a re­sult the lookups are not al­ways in­tu­itive. We would like to im­prove this and are work­ing on a new de­sign pro­posed here. Let us know what you think!

Pro­posed new prop­er­ty lookup pro­ce­dure when Atomikos starts:

1. de­fault prop­er­ties are looked up via a prop­er­ty file in the Atomikos jars (should al­ways be found) 2. over­ride with spe­cif­ic cus­tom prop­er­ties looked up in the jta.prop­er­ties file in the class­path (like now) 3. if no jta.prop­er­ties found: NO log­ging to Sys­tem.err any more (so no need to dis­able that with sys­tem props ei­ther) 4. over­ride with spe­cif­ic prop­er­ties that are set pro­gram­mat­i­cal­ly on the UserTrans­ac­tionSer­vice 5. re­solve any place­hold­er prop­er­ties (i.e., ant-style ex­pan­sion of ref­er­ences to oth­er props) 6. this yields the fi­nal prop­er­ties to use for the init pro­ce­dure

What do you think? Did we miss some­thing im­por­tant?

Thanks!