We Keep Coding

How to access MySQL database in jBoss BPM suite process

I am newbie in JBoss BPM Suite. What i want to achieve, is to access my MySQL database through a business process. I have already added a datasource to my application server including the jdbc driver. What i tried to do was to connect to my db by a script task. Although i got an exception ClassNameNotFound for my driver class 'com.mysql.jdbc.Driver'. What is the right way to connect to the db? Is there a way to do this by a service task? Or a WorkItemHandler?
Thanks in advance.

It is not recommended to execute any complicated logic (like accessing the database) in a script task. I would also assume that your application server does not put database drivers on the classpath of its applications since it is against the whole idea of datasources. You just need to make use of the datasource you have already configured.
When it comes to the right way how to connect to the database inside your process, you will need to implement your own work item handler where you can get your data from the database. There are many different ways how you can achieve this. You can find inspiration from JPAWorkItemHandler which will be available in version 7.

I have finally made the connection to my database by creating a WorkItemHandler and add it as a dependency to my BPM Suite project. After a lot of search, i think this is the best way to do it if anyone wants to access his database in a business process.

how to manage connections to dynamically created databases

I need to manage connections to multiple databases in my web app. following are facts regarding the current implementation:
1- I use Tomcat
2- databases are created dynamically at runtime ( i am using mysql)
without a doubt, having a connection pool to manage database connections is optimal.
Since the databases are not known at the start of the application, it was not possible for me to set up datasources and make connection pools. (I could not find a way in Tomcat to make dynamic connection pool: a connection pool that is created at runtime).
my question is: what other options do I have to work efficiently with connections to multiple databases ? (I don't have experience to implement connection pools myself)
is there any library that can be used with tomcat and allow me to establish multiple connection pools to different databases at runtime ? if not what do you suggest that I do instead of connection pools ?
i am fairly new with this issue therefore please correct and guide me if I am messing up concepts.
Thank you in advance.

The MySQL JDBC driver allows omitting the database name from the connection URL as follows:
jdbc:mysql://localhost:3306
You only need to specify the database by Connection#setCatalog() or directly in the SQL queries. See also its reference documentation:
If the database is not specified, the connection will be made with no default database. In this case, you will need to either call the setCatalog() method on the Connection instance or fully specify table names using the database name (that is, SELECT dbname.tablename.colname FROM dbname.tablename...) in your SQL. Not specifying the database to use upon connection is generally only useful when building tools that work with multiple databases, such as GUI database managers.
This allows you for creating a single and reuseable connection pooled datasource in Tomcat. You'll perhaps only need to rewrite your connection manager and/or SQL queries.

There are enough connection pooling framework in the open. Proxool is definitely among the best. Its pretty flexible and easy to use.

MongoDB Java Driver database connection pooling with Tomcat

According to the MongoDB Java driver documentation, database connection pooling is magically handled by the Mongo object.
Does this mean it is safe to create an instance of a singleton object which connects to the MongoDB database in a servlet that will run when Tomcat starts and not worry about configuring database connection pooling in Tomcat via the context.xml?
Is this the right way to think about it? Am I misunderstanding some basic concept of Tomcat / database connection pooling in general?

We've been using the Java drivers via the CFMongoDB project and we use it as you describe, but in a ColdFusion application rather then in Java. Same idea though: one object is created and we reuse it and that object maintains the one connection to the Mongo server.
You can create one Mongo Java instance and it will maintain an internal pool of connections (default size of 10) - to you it's hidden and you don't need to worry about it. The Mongo Java docs recommend this:
http://www.mongodb.org/display/DOCS/Java+Driver+Concurrency
We have it running in production now and there have been no issues. Multiple web request threads use the same Mongo instance and Mongo is quick enough to deal with this using it's internal pool (we're doing logging so it can write very fast!).
It is worth remembering to call close() on any instances that you are finished with - this will stop connections getting used up on the Mongo server over time:
http://api.mongodb.org/java/2.5-pre-/com/mongodb/Mongo.html#close()
So in summary, don't worry about configuring Tomcat.
Hope that helps!

Object Pooling managment algorithm

Anyone can help me to write an algorithm for object pooling. I am very new in J2EE and i need object pooling for database connection. So please help out.
Thanks

Database connection pooling is a tough problem and is difficult to get it right. However, you could use several open source solutions which offer Connection Pooling. You can consider using
C3P0 or Apache DBCP to get the connection pooling you desire.
In case you are working in an application server environment such as Glassfish, Weblogic or Jboss, connection pooling is provided by the application server itself. You need to create a datasource and enable pooling that you wish to have.

Rather than writing your own Object pool you should probably use an existing solution, e.g.
Commons Pool: http://commons.apache.org/pool (for object pools in general)
or
Commons DBCP: http://commons.apache.org/dbcp (for db connection pools)

All of the major Servlet and Java EE containers come with their own Connection pooling implementations, available through JNDI. Check the documentation with your container.

I am very new in J2EE and i need
object pooling for database
connection.
The whole point of the Java EE platform is to relief the developper form writing such infrastructure code, and focus on the business logic. Whether the platform succeeds at this or not, is another debate, but it's a least the vision.
Given that you are new to it, I would strongly suggest that you spend some time to get an better understanding of what the platform provide, and what's the vision behind it.
Connection pooling is just one thing, the platform provide specific ways to deal with configuration, security, deployment, monitoring, etc.
Regarding connection pooling specifically, see What is best approach for connection pooling?

Is DBCP (Apache Commons Database Connection Pooling) still relevant?

The JDBC 3.0 spec talks about Connection (and Prepared Statement) pooling.
We have several standalone Java programs (i.e. we are not using an application server) that have been using DBCP to provide connection pooling. Should we continue to use DBCP, or can we take advantage of the JDBC-provided pooling and get rid of DBCP?
We are using MySQL (Connector/J) and will eventually be adding SQL Server support (jTDS); it's unlikely that we'll support any other databases.
EDIT: See comment below about my attempt to eliminate the connection pooling library. It appears that DBCP is still relevant (note that some commenters recommended C3P0 over DBCP).

Based on the encouragement of other posters, I attempted to eliminate DBCP and use the MySQL JDBC driver directly (Connector/J 5.0.4). I was unable to do so.
It appears that while the driver does provide a foundation for pooling, it does not provide the most important thing: an actual pool (the source code came in handy for this). It is left up to the application server to provide this part.
I took another look at the JDBC 3.0 documentation (I have a printed copy of something labeled "Chapter 11 Connection Pooling", not sure exactly where it came from) and I can see that the MySQL driver is following the JDBC doc.
When I look at DBCP, this decision starts to make sense. Good pool management provides many options. For example, when do you purge unused connection? which connections do you purge? is there a hard or soft limit on the max number of connections in the pool? should you test a connection for "liveness" before giving it to a caller? etc.
Summary: if you're doing a standalone Java application, you need to use a connection pooling library. Connection pooling libraries are still relevant.

DBCP has serious flaws. I don't think it's appropriate for a production application, especially when so many drivers support pooling in their DataSource natively.
The straw that broke the camel's back, in my case, was when I found that the entire pool was locked the whole time a new connection attempt is made to the database. So, if something happens to your database that results in slow connections or timeouts, other threads are blocked when they try to return a connection to the pool—even though they are done using a database.
Pools are meant to improve performance, not degrade it. DBCP is naive, complicated, and outdated.

I prefer using dbcp or c3p0 because they are vendor neutral. I found out, at least with mysql or oracle, that whenever I try to do something with the jdbc client that is not standard sql I have to introduce compile-time dependency on the vendor's classes. See, for example, a very annoying example here.
I am not sure about mysql, but oracle uses their specific, non-standard classes for connection pooling.

People still use DBCP, I think it even comes as a default with Hibernate.
Is DBCP not meeting your current needs?
I'm not a big believer in replacing infrastructure unless there's already a performance or functionality gap that it can't fill, even if there are newer or fancier alternatives around.