We Keep Coding

Running DB2 java stored procedures in single process

It seems, that DB2 creates new process for each connection when running java stored procedures in it (for example, procedures, which are called from trigger on some table update event).
The question is: is any way for running all java stored procedures in single process, so we could share static values between them?

DB2 will force multi-process model execution of your stored procedures.
I would suggest you to just send your data to a message queue, and have an application listening to that queue handle the data and do the logging. Take a look at for example RabbitMQ, Apache ActiveMQ, or ZeroMQ.
This would be probably trivial to implement, but it requires usually that you have a daemon with your application logic running. This is true unless you configure the message queue product to spawn your application logic automatically - which is usually possible with message queue products but requires a bit more configuration.

Unfortunately, I have to give a negative answer to my own question.
According to this paper: Static and non-final variables in a Java routine exactly what I'd like to do is impossible.

Apache Camel - JDBC Stored Procedures and transaction handling doubts

I'm trying to build a small, proof of concept, Camel based application (running on FuseESB) which will possibly replace part of our existing integration system build on EJB's.
Right now, I'm trying to figure out the best way to handle the following scenario with apache camel:
JMS text message comes in
I have to execute a series of database operations based on the message content, invoking mainly stored precedures/functions
from the results acquired by the db calls I have to construct a reply message and send it to specific jms queue.
In case of an error/exception I would like to use a dead letter channel handling mechanism.
I can build simple camel routes, handling errors and exceptions in camel looks easy too, what I don't get is how to use Camel SQL component (I understand that JDBC component cannot be a transactional client) to make all my db calls as part of single transaction. From what I found on the net Camel SQL component cannot be used to execute stored procedures - is it true? If it is, should I use Processors or simple pojo classes to do my jdbc calls? What about transactions in the case of using pojo or processor types? I would highly appreciate any pointers to resources describing how to handle such a use case.

I would suggest to use a Java Bean to do the JDBC interaction, since you want to do multiple calls and use stored procedures. Sometimes Java code is easier.
For example the Spring JdbcTemplate have a good abstraction over the JDK JDBC API and makes it fairly easy to call stored procedures.
Alternative then MyBatis have support for calling stored procedures as well.
http://loianegroner.com/2011/03/ibatis-mybatis-working-with-stored-procedures/
And there is a camel-mybatis component as well.

Oracle/Java application, recommended architectures

I am working on a desktop Java application that is supposed to connect to an Oracle database via a proxy which can be a Servlet or an EJB or something else that you can suggest.
My question is that what architecture should be used?
Simple Servlets as proxy between client and database, that connects to the database and sends results back to the client.
An enterprise application with EJBs and remote interfaces to access the database
Any other options that I haven't thought of.
Thanks

Depending on how scalable you want the solution to be, you can make a choice.
EJB (3) can make a good choice but then you need a full blown app server.
You can connect directly using jdbc but that will expose url of db (expose as in every client desktop app will make a connection to the DB. you can not pool, and lose lot of flexibilities). I would not recommend going this path unless your app is really a simple one.
You can create a servlet to act as proxy but its tedious and not as scalable. You will have to write lot of code at both ends
What i would recommend is creating a REST based service that performs desired operations on the DB and consume this in your desktop app.

Start off simple. I would begin with a simple servlet/JDBC-based solution and get the system working end-to-end. From that point, consider:
do you want to make use of conenction pooling (most likely). Consider C3P0 / Apache DBCP
do you want to embrace a framework like Spring ? You can migrate to this gradually, and start with using the servlet MVC capabilities, IoC etc. and use more complex solutions as you require
Do you want to use an ORM ? Do you have complex object graphs that you're persisting/querying, and will an ORM simplify your development ?
If you do decide to take this approach, make sure your architecture is well-layered, so you can swap out (say) raw JDBC in favour of an ORM, and that your development is test-driven, such that you have sufficient test cases to confirm that your solution works whilst you're performing the above migrations.
Note that you may never finalise on a solution. As your requirements change, and your application scales, you'll likely want to swap in/out the technology most suitable for your current requirements. Consequently the architecture of your app is more important than the particular toolset that you choose.

Direct usage of JDBC through some ORM (Hibernate for example) ?
If you're developing a stand-alone application, better keep it simple. In order to use ORM or other frameworks you don't need a J2EE App Server (and all the complexity it takes with it).
If you need to exchange huge amounts of data between the DB and the application, just forget about EJBs, Servlets and Web Services, and just go with Hibernate (or directly with plain old JDBC).
A REST based Web Services solution may be good, as long as you don't have complex data, and high numbers (try to profile how long does it takes to actually unmarshal SOAP messages back and to java objects).

I have had a great deal of success with using Spring-remoting and a servlet based approach. This is a great setup for development as well, since you can easily test your code without deploying to an web container.
You start by defining a service interface to retrieve/store your data (POJO's).
Create the implementation, which can use ORM, straight JDBC or some pooling library (container provided or 3rd party). This is irrelevant to the remote deployment.
Develop your application which uses this service directly (no deployment to a server).
When you are satisfied with everything, wrap your implementation in a war and deploy with the Spring DispatcherServlet. If you use maven, it can be done via the war plugin
Configure the desktop to use the service via Spring remoting.
I have found the ability to easily develop the code by running the service as part of the application to be a huge advantage over developing/debugging something running on a server. I have used this approach both with and without an EJB, although the EJB was still accessed via the servlet in our particular case. Only service to service calls used the EJB directly (also using Spring remoting).

invoking batch script/Java code from Oracle database

I have a requirment, of invoking a Java file from Oracle database. In my project, whole of my business logic is in database, but there is a requirement of invoking a third party system (SOAP / RMI call) from my application.
Now for this i need to invoke atleast a Java Code or a batch script file (depending on Windows(.bat) Or Linux(.sh)).
Thanks

Try this page: http://www.cs.umbc.edu/portal/help/oracle8/java.815/a64686/04_call2.htm
You can can Java-Code from your PL/SQL.

Web-service call outs can be done from the Oracle Database. I'm not sure why you need to use Java for this as PL/SQL also allows for outbound calls using UTL_DBWS.
If you do not intend to use JPublisher, or you have a very simple web-service to consume, then you can use UTL_HTTP itself, or the appropriate class in Java - HttpURLConnection. However, I've never seen any case where a JAX-RPC library or any other web-service library was loaded into the database using loadjava, and used to make web-service calls; it ought to be possible do so, as long as the library is very light (in not depending on other libraries that cannot be loaded or used in the database), and requires permissions only to connect out from the database.
Related question
Access Web service from Oracle stored procedure

Java EE and application servers - What can i do?

I decided that it is time for me to dig into the whole Java EE stuff. I am using EE some techniques whithin Java SE like JPA or JMS, but i still messing around with Java SE and i believe Java EE and an application server will solve some of my problems i have.
BUT: I have still some questions after reading some articles on the web.
1st: Am i limited to request-response applications? I have an application which serves XML documents via HTTP. All delivered objects are added to a queue which will be dispatched in a different thread. Some validation is made for this objectes, including the opening of sockets to a remote machine (I heard EJ-Beans are not allowed to do this, is this true?). So, is is possible to do this within an application server?
2nd: I know there are Message driven beans, is it possible to send JMS messages to a MDB from outside of the application server? I have a service which sends JMS messages, but runs, as a legacy system, not inside the same application server.
3rd: How can the System Adminstrator or User configure my application? I know that some things like database connections are configured within the application server and my application can lookup them via JNDI or get them via DI. But what about application specific configuration?
Yeah, these are quite noobish questions, but maybe someone has the time to explain me how all this stuff is working. :)
regards,
Posix
PS:
4th: It seems EJBs are not allowed to do anything with files, so Java EE seems to be no option for a Service which receives Files, pushes them around to different systems and want them to write to a Socket (see question 1)?

I can say that Java EE can be used without any doubts in your case. Let me drill a little bit more into your specific questions:
You can open socket connection from your EJB. There is nothing that prevents you from doing that. However this kind of operation is not advised for Java EE applications. In my opinion the better option is to implement Java EE Connector (JCA) that would manage pool of socket connections to your proprietary system. This is the model way to implement such a integration as per specification.
Yes! It is perfectly possible to receive messages send from external application/system (outside the AS). This is main idea of integration using messaging :) In many cases your application being Java EE application receives messages via MDB from JMS channel, but JMS is only an API and can be implemented by any messaging system e.g. IBM MQ. In this architecture the external system puts an MQ message onto the queue and your Java EE application that listens to the very queue receives the message via JMS API!
Generally speaking Application Server gives the Administrator great tools to manage Java EE resources i.e. data sources, JMS connection factories, JMS destinations, JTA transaction manager, etc. If you require the ability to change your specific Java EE application the best options seems to be JMX. Just implement a few MBeans, export those to the JMX server embedded within your Application Server and you are done. This task is really trivial in, say, JBoss, but most of the modern Application Servers offer extensive JMX capabilities these days.
For the first glance, EJB doesn't seem to be the best for dealing with files. But remember that implementation of your EJBs is still written in pure Java, so nothing prevents you from reading/streaming files and so on. I have experience with large Java EE applications that are handling large files as input files and can assure you that Java EE is is a good technology choice :)

Here are the restrictions on EJB 1.1 spec.
Here's my take on your questions:
I believe an EJB can open a socket on a remote machine, but I would say that opening sockets is too low level an operation. I'd think about exposing whatever that socket is doing for you as another EJB.
An MDB is just a listener that's registered with a particular topic or queue. It doesn't say anything about sending. If your client knows how to get a message to the queue it's possible. They just have to know the queue URL and be able to create a connection.
The admin sets up connection pools, JNDI names, etc. - everything. They do it using the admin console for the app server.

It's a violation of the EE spec to do anything with files (to ensure that an EE app is portable and distributable). However since it's all just plain Java code, yopu can choose to do anything that you want. As long as you know how your target environment looks (eg the system is for internal use) I wouldn't hesitate modifying files just because the spec says so.

In an application server like Tomcat (others too, probably, but I've never worked with them) you can not only execute things upon receiving a request, but also do things (including starting long running threads) on server startup. Basically you can do anything that you can with "normal" Java. In fact, you could put a normal Java app in application server if you just include a piece of code which calls the appropriate main() on server startup.

I would suggest applying each technology to the appropriate points where you are currently feeling pain. Regarding your specific points,
In an EE context, you would add the messages to a JMS queue, that has MDBs which would do the actual processing. Regarding the management of the HTTP request/response lifecycle, you would manage this the same way you do now, or use an existing library to do if for you. By moving to an EE app server, you would allow the app server to manage the threading, transactions, etc. instead of having to manage it manually.
As duffymo stated, MDBs are responsible for receiving messages, they do not care where the message originated from.
The system administrator can configure the app server as duffymo stated. Additionally, you can expose JMX beans to other systems or to the end user to allow them to configure services if you so desire.