New Version 3.1 of ExpressionOasis Released

New version 3.1 of ExpressionOasis has been released.

Release Notes: 

  1. Grammar class is made configurable now. Developers can implement custom Grammar class and can specify this in configuration. ExpressionOasis will pick this at runtime. 
  2. Made grammar.xml path configurable by exporting it to config.xml
  3. Improved code of ExpressionFactory to improve the performance
  4. Defined new way to add function definition by providing new API in Grammar interface 
  5. Exposed Grammar through ExpressionEngine Class, so that user can get the metadata if required and also can add specific metadata like custom function identification etc
  6. Added three new String operation expressions > startsWith, endsWith, contains (Contribution by Girish Kumar) 
  7. Made config.xml path configurable from System Property (Contribution by Girish Kumar)
  8. Improved documentation
In case of any issue or any new requirement, please log it here. If you are extending the framework to add new features, please consider to contribute these back to the project. It will help everybody whosoever is using the ExpressionOasis.

Follow us:

Spring RoutingDataSource to Work with Multiple DataSources

Finally back to blogging. It was a long journey to get ready, pick the pen (i.e. computer) and start writing again. Writing is a matter of habit.

Today we are going to discuss about using multiple data sources with Spring Transaction Management. Scenario is,

  • Application is having lot of legacy code
  • Application needs to work with more than one databases
  • There are some legacy methods in application which are supposed to work with any one of the database depending upon use case. Same method could be invoked with different data source context for other transaction.
  • Application is using Spring Transaction Management
  • Requirement of Spring Transaction Management is to declare data sources and associated transaction manager with application context (1 to 1 relation)

What would be the initial design considerations. 
  • Define all required data sources in application context
  • Define corresponding transaction managers too
  • Use any of the Persistent Template to implement the DAOs.
  • Define desired transaction behavior on service methods

We are done with basic infrastructure code. In above steps, missing part is how to tell application code about which data source to be used from multiple data sources defined in context. It can be done by specifying the specific transaction manager (related to desired data source) with Service transactional attributes. Transaction manager can be defined either at class level or at method level. Or a good approach could be to use Transactional advice and define the transaction manager in context configuration with a pattern to identify the methods. 

A general workflow would be; whenever any service method is called using Spring Framework, Spring will see if there is any transaction proxy available for that method. If yes, transaction proxy will get invoked. It will work with defined transaction manager and will start a new or use existing transaction (based on transaction attributes). It will also try to attach the connection with the current transaction (thread local based implementation). Connection will be retrieved from the data source which is associated with the transaction manager (defined in context). This connection will be linked with current transaction as synchronized resource. Please note, that connection may be attached lazily in case of 'LazyConnectionDataSourceProxy'. In this way, Spring enables the scenario to use multiple data sources in application based on specified transaction manager.  All the methods invoked during the service call, or from nested methods will go to the database which is associated with current transaction manager (and the data source).