I am looking for a simple way of using xa transactions from DB2 stored procedure.
I have found many links and articles using JDBC and XAConnection in DB2, but what I am looking for is use of XA transactions from a procedure stored in the DB2 database. Nothing java, only I couldn't manage to find any valuable resource.
I have only found this page, but I could manage to get any further.
Many many thanks for your answers,
Kim
This cannot work. XA requires an external transaction manager.
Related
For database management, my team right now is using a RDBMS based solution (MSSQL to be exact), but we expect to move to Cassandra soon as we're expecting a huge bump in traffic.
The application logic right now is decoupled from insertion logic, as the application only calls the specific procedures in SQL which calls some data validations and makes corresponding insertions.
I want to do something similar in Cassandra. However, I am unable to find anything that could aid me in doing so. UDFs are not useful as they are mostly used in SELECT query. I'd appreciate the community's help/advice on this, thanks!
The closest feature to a stored procedure will be a batch as it will allow you to "bundle" different DML statements associated to an insert, update or delete.
If you are moving from RDBMS to Cassandra, one of the biggest challenges is to adjust to the data modeling required, and more specific, to denormalization of data. The data model is the key factor of success (and failure) of any Cassandra implementation, and because of that, you may find several resources in the web (to mention the basics eBay blog, Datastax academy's Data model course)
Good luck with your implementation!
For example, the original SP include several IN parameters and SQLs. Now, I used java application which implemented each SQLs and used Oozie to simulate the whole process/workflow in Oracle SP, not sure if it is the right way. Could you please provide some advices?
Thanks in advance!
You can use CTE (Common Table Expressions) to model your queries. Stored procedures as database objects are not supported in Hive/Impala yet. You may want to have a look here
Hi
I have the database with huge data. there are several master-detail relationships within it. so i just wanted to build the Views / stored procedure so that data fetching get much faster. I know I can use Index. but i saw it is a limitation in sql server express version. where as i am using express version. so how to perform this in express version. please guide me .
Creating a stored procedure won't speed up query execution.
Making sure that your foreign keys are indexed is the first step.
The definite answer to the question of query performance will give you a look at query execution plan. Make sure you don't have any Table Scans / Table Seeks.
In this OLE DB msdn example, (yes, it is dated 1997, but still works :)) I'm wondering what the historic point of OLE DB was if you still apparently wrote SQL to interact with the underlying datasource.
The one thing I'm thinking is if the ICommandText was not executed directly on the database, but instead somehow interpretted by OLE DB then passed off as a vendor specific SQL command/command to manipulate underlying datasource in format it understands. Is that true?
The intent of OLE DB technology is to have a generalized way to connect, work with transactions, and work with datasets. But you still have to write SQL queries. Remember, the intent of the SQL language was to have a generic language for querying data (but, as you've seen, certain parts of the language are platform-dependent). How you connect and how you query are mutually exclusive.
And, yes, the CommandText is executed directly in the database.
Perhaps you want something a level up such as NHibernate, Subsonic, Entity Framework, etc.?
I can vouch for the fact that there is NO translation done by OLE DB.
If you have different databases, you would have to provide different SQL statements based on the vendor. Always fun with dates and Oracle vs. MS databases...
With newer versions of DB2 you can write stored procedures in SQL or you can create procedures in Java (or other languages) that can then be added to the database and called just like SQL procedures. I'm wondering what the the pros and cons of each method are. I'm specifically interested in comparing those two types of procedures, not debating procedures versus external code which I think has already been covered. Here is what I've come up with so far:
SQL:
Better performance for basic SQL functionality
Less verbose for simple logic, i.e. you can run SQL directly
No extra compile step - just create procedure ...
Java:
More structured and full-featured code (classes, objects, reuse, libraries)
Better resources for help both in terms of programmers and documentation
Any other thoughts?
Not just Java but any procedural language: procedural, that's the key.
DB2 is a relational algebra, not a programming language. If you need to do something complex, it's better to use a procedural language than try to bend SQL into something it's not meant to be.
We actually use REXX for our DB2/z work but I've seen guys here use bash on the mainframe for quick prototyping. Some who only use SQL create all these horrible temporary tables for storing things that are best kept in structures and away from the DB.
My thoughts are that complexity is the only differentiating factor between using SQL directly in a stored procedure and a procedural approach. We have two rules of thumb when making these decisions.
1/ If a unit of work requires more than two trips to the database, we make it a stored procedure.
2/ If a stored procedures creates a temporary table, then we use a procedural language to do it.
You may already have found this but just in case and for any others that swing by here there's an IBM Redbook on SProcs and the changes for DB2 v9 available at
DB2 9 for z/OS Stored Procedures: Through the CALL and Beyond
which discusses the available options and their relative merits.
The advantage with the SQL stored procedures is they are portable to other Db2 UDb with minimal or no changes. But Db2 external procedures would be a better choice as you can do more with a procedural language than sql alone.
I would say cobol would be a better fit for DB2 external stored procedures than Java for the below reasons.
1). You would be able to reuse some code from existing programs. Converting a cobol sub program to a stored procedure or stored procedure to a cobol sub program is very easy to accomplish.
2). You would be able to use existing cobol development team who has functional knowledge with the system.