If I expose DataSource as a service in OSGI, how should I handle database connection failure? Should I configure an interceptor of the DataSource service, which would catch database connection failure exception and unregister the DataSource service? Or would OSGI container handle the exception for me?
How should I configure the consuming service, so that it would be able to survive unavailability of the DataSource service, and allow user to re-try the transaction again?
You should handle unexpected exceptions in the same way as you do when you do not use OSGi.
You should use connection-pool and register that as an OSGi service. It will handle connection failures for you. You must always close the connection, even if there is an exception during using that connection. (in finally block before java 6 and by using a try-with-resources block after java 7). Connection pools provide their functionality by implementing DataSource interface.
There are many connection-pools. You can google for them.
I implemented two OSGi components based on commons-dbcp. One for pooling regular DataSources and one for pooling XADataSources. The component picks up the original DataSource/XADataSource OSGi service, than registers a new pooled-DataSource OSGi service.
You can find the source of the module here: https://github.com/everit-org/commons-dbcp-component
It is available at maven-central here: http://search.maven.org/#artifactdetails%7Corg.everit.osgi%7Corg.everit.osgi.jdbc.commons.dbcp%7C2.0.1%7Cbundle
After dropping the jar into your OSGi container, you will see the configuration possibilities of the components at the Configuration page of WebConsole (if you have webconsole).
Related
In a Spring Boot application using Log4j2, I have setup a DataSource via yaml-configuration. But since Log4j2 needs a connection pool already in the startup phase for its JDBC Appender, a second data source must be provided separately. This results in the application having two connection pools running, both writing to the same database.
My first question is:
Are there any concerns about this setup, or is this the normal approach anyway?
Alternatively, the following setup would come to mind: we programmatically initialize the DataSource, so that we have access to it. Further on, we can then programmatically extend the existing Log4j2 configuration that doesn't have a JDBC Appender yet. By doing so we can pass the pooled DataSource that we also use for the application itself.
My second question is therefore:
Are there any caveats to using the same DataSource for both the application and the Log4j2 logging framework?
Many thanks for any information that helps to clarify the situation.
I am trying to understand the transaction management in Spring, and I have got some doubts.
I read a bit about transaction management in EJB world, which can be CMT or BMT. For CMT, as per the documentation, it is Application server (e.g. JBOSS) which manages the transaction.
Now, coming to Spring transaction management, and considering using Web container only (Apache Tomcat), how does this work?
Does Spring have its own transaction management with capability of handling local transaction and global transaction (which works with 2 phase commit). Do the actual support need to come by the underlying container (in this case Apache tomcat) or support from framework is sufficient?
I am not clear how all these pieces fit together.
Can anyone help me understand this?
Spring doesn't include any kind of transaction capability of its own, it only provides ways to connect to transaction functionality provided by the container or by standalone libraries.
If you run your application on Tomcat and don't provide any transaction manager libraries like bitronix, then you get only local jdbc transactions provided by the servlet container.
When you read the bullet points at https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html notice it says spring is providing abstractions, that means it is providing access through its own apis and using aop to make transactions nonintrusive, but not providing any implementation of transactional functionality. It's facilitating gluing things together, which is the main thing spring does.
I'd like to add XA connection pool to my Spring based application, specifically Oracle UCP. This pool works on XADataSource and XAConnection objects. Standard DataSource.getConnection(...) methods are not supported.
Trying working with that pool (that I am able to successfully set up in Spring) I am getting an error related to the fact that getConnection(...) methods invoked by JdbcTemplate are disabled and should not be used. I am just wondering whether any of Spring JDBC classes are able to work with XADataSource and XAConnections? Probably there are another ways to use Spring with XA connection pools? Will appreciate any advices on that topic.
Just for those who may experience similar problems - Spring doesn't support directly XA connection pools (through native XADataSource.getXAConnection(...) methods). You need to write a kind of wrapper utilizing DatSource.getConnection(...) methods.
Need to call a EJB service from the servlet context listener's contextInitialized() method. Application is running on JBOSS, though the context listener works fine, I'm not able to access the EJB bean through JNDI look up.
Because the web deployment in JBOSS happens before EJB beans are bound with JNDI tree. How to overcome from this? Is there a way to configure JNDI bind early or start the web deployment later once EJB's are completely deployed?
I had put Thread.sleep() before the service call in the contextInitialized() method, it is working fine in my JBoss5.1.0 GA, and the same did not work in other machines JBoss of same version.
Applications needs this because, we want to load some master data from the DB and make it available in the web layer (kind of caching). Does JBOSS startupmbean suit this requirement? If yes how can I make the data available to web layer?
Also if any alternative ways are available, please suggest.
Poll for the EJBs in contextInitialized(). So instead of just sleeping for a certain time, try to connect to the EJB. If that fails, sleep, and retry, until the EJBs are available. In this case the context initialization is blocked.
Implement the cache as a lazy one: Fill the cache during the first query (and use the same polling procedure: connect to the EJB, retry until it becomes available). In this case the cache blocks.
You could split your deployment into two parts: One for the EJBs, one for the web application. Then deploy the first, and delay deployment of the web application until the EJBs are bound (either by watching the log file or by trying bind to the EJB from a command line app)
To process a large number of messages coming to a queue i need guarantee of at least one jms connection to be there at any time. I am using spring and spring allows to have multiple sessions on a single connection only. In case one and only connection fails, application will come to standstill till spring reconnects to the JMS bridge.
So how can i create more than one connection to a queue in Spring, also how can i do connection pooling here.
The answer to this depends on whether you are using Spring inside a J2EE container(jboss etc.) or in a standalone application.
Standalone - you'll find pooling connections to be a problem. Springs SingleConnectionFactory can be setup to renew the connection on an exception garaunteeing that at some point a connection will come online and start processing the queue again, but you'll still have the problem of waiting for that single connection to renew, plus depending on what messaging implementation your dealing with and how it does load balancing you may find yourself stuck with a connection to a single node in a cluster.
If you are running in a container you can rely on the containers connection factory which will be much more robust. JBoss Messaging in the container for instance will failover seamlessly to other nodes and handles pooling under the covers, but if your working in the container its usually easier to bail on JMS template which kind of sucks and use whatever that container provides.