Sunday 20 May 2012

Atomikos and Oracle AQ: connections pool problem



Don't use Atomikos jms ConnectionFactoryBean pooling with Oracle AQ as they recommend in documentation! You will not use the pool indeed. How to use it right?

In example from Atomikos documentation we are creating oracleDataSource and AQJmsFactory uses it to create XA factory.
And Atomikos JMS factory bean works like an adapter/decorator for this XA factory to make it transaction-aware and to create connection pool:


oracle.jdbc.xa.client.OracleXADataSource  xaDataSource = new oracle.jdbc.xa.client.OracleXADataSource();
XAQueueConnectionFactory xaQueueConnectionFactory = AQjmsFactory.getXAQueueConnectionFactory ( xads );
AtomikosConnectionFactoryBean pooledQueueConnectionFactoryBean = new AtomikosConnectionFactoryBean();
pooledQueueConnectionFactoryBean.setXaConnectionFactory ( xaQueueConnectionFactory ); 
//...set pool settings in pooledQueueConnectionFactoryBean ...


But behind the scene if you will profile application which uses this code, you will find that Atomikos have no access to JMS connection to use it in pool(naturally, as Oracle AQ uses jdbc connection instead) and each closeSession delegates to Oracle AQ conn factory which calls PhysicalConnection.close() on jdbc connection. And pool is not working as expected. If your app has few listeners and each of them calls receive frequently you will create/close jdbc connections each time and performance would be horrible.

The problem also is that you can't enable connection caching in OracleXADataSource and use it's pool(if you will do this AQjmsFactory will throw exception), and dbcp and c3p0 pools are not working either as AQ doesn't work with proxy this implementations create around instance of oracle connection.

The only solution which works for us is to use atomikos xaDataSourceBean and than non-xa jms queue connection factory:

oracle.jdbc.xa.client.OracleXADataSource xaDataSource = new oracle.jdbc.xa.client.OracleXADataSource();
AtomikosDataSourceBean pooledDataSourceBean = new AtomikosDataSourceBean();
pooledDataSourceBean.setXaDataSource(xaDataSource);
//...set pool settings in pooledDataSourceBean ...
QueueConnectionFactory queueConnectionFactory = AQjmsFactory.getQueueConnectionFactory ( pooledDataSourceBean );


This will allow you to use XA-aware data source and atomikos connection pool now will work, as it is between AQ JMS connection factory and db data source.

Monday 9 April 2012

OOP Patterns in functional language

The topic was inspired by my Master Thesis, which I have handed in recently but I want to proceed working on it as haven't done it properly.

The thing I tried to do - to implement OOP patterns in functional language - Erlang.
Resulted sources are at github

A lot of developers will admit that it doesn't worth the attempt because of difference in paradigms and because most of OOP patterns are already implemented naturally in FP languages.

I was trying to describe my goals in thesis(paper)  and below is some part from introduction:

Today it is realy hard to find software developer who hadn't heard about design patterns and refactoring techniques.
This terms became very popular few years ago and are very widely used in modern software development.
I remember when I heard the first time at second year of study about patterns and read few articles about it - I was very delighted with this new world and interesting methods of code organization and become very enthusiastic about patterns.
The problem which really caused me to choose the subject for thesis is that "Design Patterns" in our mind is very closely associated with Object-Oriented paradigm.
Since the time of GoF book design patterns where very popular subject for different researches, discussions and pulications, they had a lot of heads involved and thats why the topic was developed very quickly and have now a huge base.
But the problem was that most of this researches and publications were about implementation and application of patterns/refactoring to Object-Oriented paradigm. It was most popular and authors used it as primary in their work. Other paradigms had no such careful attention, and it is black side of OOP monopolism in enterprise application development.
I always have been a loyal supporter of functional paradigm, so I aways wanted to have this gap filled at least in this paradigm.
In order to do classic patterns in functional languages we should escape from OO paradigm limitations. As well we should have new patterns suggested by functional languages.
After developing for over four years in at work(mostly Java), I was pretty comfortable with best practices for creating applications in OO languages.
But when I tried to create my first application in Erlang(am not taking into account Lisp samples written during very short academic course), I ran into all sorts of problems. You can feel it even trying to write any complex XSLT with parsing and recursion.
But I have realized that what I was trying to do was use an OO approach in a functional programming language. There were fundamental differences between the two approaches, and "paradigm shift" is not just yet another philosophic phrase.
Another idea is that to make functional paradigm more popular and widely used we need to involve to it a part of experienced OOP "Coryphaeus". Because functional programming encompasses a very different way of composing programs, programmers who are used to the imperative paradigm can find it difficult to learn.
So I think that it would be very useful to show comparison/make mapping between well-known OOP design patterns and functional analogues, and to create last ones if we need that.
In process of making such comparison we would find out problems and gaps of each paradigm in regard to patterns and refactoring techniques.
Hope it would be helpful for students as well when they try to learn course in functional languages. As at such courses we usually do not have time to look at FP in depth, and are only learning basic syntax. This fact causes us not to think about FP as something which can be used in real life, in production.
But as far as most of students are aware of OOP design principles and patterns, it would be interesting for them to find out that the same problems/tasks can be solved in functional languages in much easier and straight-forward way. 

Thursday 8 March 2012

Preface

Why "Think Functional"?

Sure, the first guess about my love to functional paradigm has some place, but not the main one.

The name of blog appeared eventually. I tried to play with different paradigms, languages, technologies, approaches during my not so long, but intensive programmer's life. Was a bit tired of numerous holy wars and discussions like "Who is the coolest and whose languages/tools are the best".
I was very young and idealistic.
I am still young and still idealistic=)
But after facing a not-so-ideal-reality at different projects I started to listen more and to try to learn more from others, and not to be stubborn fanatic.
At the beginning I couldn't understand why older and more experienced colleagues where so pessimistic and careful. Why business never understands our dreams about ideal requirements which follow strict logic and can be implemented in the most ideal way. Why we are always late with delivery. Why...why...why
My attitude was changed dramatically. Sure it would mutate later.

But at the moment I think we need to apply ideas of functional programming to our way of thinking.


Functional - strict mathematics-based approach - teaches us to have proven decision/result, based on lower-existing rules and axioms. 

I need to start to think about results of development like about mathematics:

  • To always have exactly one result of function application (result - delivered product, which satisfies the requirements of client)
  • Result should be calculated in appropriate time (product should be delivered in time)
  • We should prove that result is correct (product should pass acceptance tests, based on requirements and should be successfully used by end users)
Sounds like a mess of ideal phrases from PragmaticProgrammer's books shell and agile principles, isn't it?
Think it is obvious and nobody will deny that three statements(in brackets) are the only thing client wants from us and is paying for.
But how to reach this ideal situation?
As I am trying to represent any statement in form of functional/mathematical style, 
I have created a formula for myself, which is in blog description: 

success=function(programming(dream, love, hard_work, discipline))
where level of success - function of programming with 4 arguments/circumstances, and the measure of those three ideal statements satisfaction.

The function means that success depends on 4 arguments, and if you forgot one of them or hadn't commited any of them enough - you will not have achieve the goal.

 So I should Think Functional - return result like function, follow strict mathematical theory doing my work, work hardly, be pragmatic, love the thing I am doing and to follow discipline - good practices and code beauty.

Inspired by developers and MMA trainers I met on my way.
See also ideas of SoftwareCraftsmanship ,  OnePragmaticProgrammerAboutTechnologiesVsProblem and hundreds of other articles and books=)