I have created a Service running on Tibco, containing a JDBC-enabled process within it, and tested it successfully. The database server is MySQL, and is hosted remotely. When connecting to the remote DB from the service hosted on my machine, the SQL is executed well, but after building the Tibco EAR file and deploying to another external machine, then trying to access the same remote DB server using the same credentials, the external machine returns the below error upon returning:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OPTION SQL_SELECT_LIMIT=DEFAULT' at line 1
So, a few questions:
What could be the cause of the above error, given the DB being accessed is the exact same one, using same SQL query, but from different machines?
Is the JDBC driver used for development compiled as part of the packaged EAR file?
Does the JDBC driver being used in a Tibco Process depend on the Tibco service installed or on the packaged EAR file?
Am asking from a learner PoV as am currently picking up Tibco
It looks like jdbc driver issue. You may have different mysql driver version in tibco designer and BusinessWorks.
You don't need to add jdbc driver to your ear package.
Please note that you can specify mysql driver in your package classpath. In tibco Administrator PackageName->Configuration->ServerSettings->Prepend to ClassPath or Append to Class path.
You can also try to copy the driver from your tibco designer(in BW5 it's in \tibco\bw\5.11\lib\
) to the BusinessWorks classpath
Related
I am learning Spring Boot using open-source projects and have stumbled upon their demo project — PetClinic. It has two possible databases configured: MySQL & HSQLDB, it uses the latter by default.
So I was able to launch the project look at it on localhost and can see that the DB (HSQLDB) is being populated but I was unable to set up a connection through the Intellij IDEA because the project does not specify the path that allows to see the contents of this in-memory DB.
Can anyone please tell me, what am I missing in the process of establishing the connection to HSQLDB here?
Thanks!
You can't connect to an in-memory instance of HSQLDB from another process.
The main drawback [of in-memory mode] is that it is not possible by default to connect to
the database from outside your application. As a result you cannot
check the contents of the database with external tools such as
Database Manager while your application is running.
If you want to do this, you need to run HSQL as a server. More details about how to run it in server mode can be found here.
I am not able to connect to my HSQLDB database from RazorSQL. I am only having this issue when I am running in Server mode and when I am attempting to connect from RazorSQL.
Using the same URL from Eclipse Data Source Explorer, and from the application itself (which is a Hibernate 5.2.7 application), I am able to successfully connect to my database at the URL "jdbc:hsqldb:hsql://localhost/SudokuHibernate". Since I am running it in Server mode, I am able to connect concurrently.
(Note: I don't have to have multiple concurrent connections, but it make debugging easier). The database is being run in Server mode from the command line via ...
java -cp ../libs/hsqldb-2.3.4/hsqldb/lib/hsqldb.jar org.hsqldb.server.Server --database.0 file:/Users/arick/src/databases/SudokuHibernate --dbname.0 SudokuHibernate
When attempting to connect from RazorSQL, the database console shows the error message. "org.hsqldb.HsqlException: Client driver version greater than '2.1.0.0' is required. The HSQLDB server version is '2.3.4'".
Note: This is a different question then a similar StackOverflow question, as all of my own configuration files are explicitly referencing the same JDBC driver, from the same jar file. However, as pointed out by Fred T, the reference to '2.1.0.0', by HSQLDB, is somewhat misleading. It is really just saying that the client and the server have two different versions of the JDBC driver.
At the same time that the database is throwing a mismatched version error, RazorSQL displays a dialog box with the error message:
ERROR: An error occurred while trying to make a connection to the database:
JDBC URL: jdbc:hsqldb:hsql://localhost/SudokuHibernate
connection exception: connection failure: java.io.EOFException
Below is my RazorSQL connection profile.
RazorSQL Profile
Driver Location: /Users/arick/src/libs/hsqldb-2.3.4/hsqldb/lib/hsqldb.jar
JDBC URL: jdbc:hsqldb:hsql://localhost/SudokuHibernate
As was inferred by Mark Rotteveel, the answer is similar to a related question about how to get Eclipse and Maven to talk to a HSQLDB server that is running in standalone server mode.
In that case, Fred Toussi, the lead on the HSQLDB project, pointed out the answer was to modify the configuration file, that is used in Eclipse and Maven, to pull in the appropriate version of the HSQLDB JDBC jar file, and also to make sure the jar file didn't appear anywhere else on the classpath. Maven uses a pom.xml file for configuration; so what was needed was make sure that the correct version of the HSQLDB was defined in the project's pom.xml file.
In my situation, the RazorSQL product that I was using, just happens to use HSQLDB as the embedded database for itself. If I had been using any other Java database, I may not have had this problem. But, since the RazorSQL product had already loaded its own version of the HSQLDB jar file, it didn't matter what I specified in my configuration for the database connection. It wasn't going to work.
No matter how I changed my driver profile, or my connection profile, the only version of the HSQLDB jar file that was going to get loaded, was the original jar file, that was already in use by RazorSQL, and that came with RazorSQL. (Note: This is true, unless RazorSQL gets fancy, and it decides to use a different classloader, and some of the other tricks that are commonly used by Java applications servers to solve these problems).
As per suggestion from Dan Richardson, from RazorSQL, the actual answer was not by modifying my configurations, but by changing the contents of the RazorSQL distribution itself. I needed to replace the jar file that is used by the RazorSQL application. This jar file is in Mac application folder for RazorSQL. This location is typically at /Applications/RazorSQL.app/Contents/Java/drivers/hsqldb.
(Note: If you are not familiar with how to open a Mac app folder, you just right-click on the RazorSQL folder name in the /Applications directory and use the "Show Package Contents" menu option). In my case, I renamed the original hsqldb.jar file to be hsqldb_2.3.2.jar file, and then I copied in the last distribution of the hsqldb.jar.
I am trying to install WebSphere using Puppet Configuration Management. I have installed the module "puppet module install joshbeard-websphere" and started working on the same.
I am facing 2 issues:
After the "websphere::profile::dmgr" runs successfully I still don't get the SOAP port. It is mentioned that after successful run on client:
When a DMGR profile is created, this module will use Puppet's exported resources to export a file resource that contains information needed for application servers to federate with it. This includes the SOAP port and the host name (fqdn).
Is there something I am missing?
This module supports creating JDBC providers and data sources. At this time, it does not support the removal of JDBC providers or datasources or changing their configuration after they're created.
This link explains the new things about WildFly. Under the Migrating The Database Connection -> JDBC Driver the article explains about two ways of using jdbc drivers for the applications. I tried with installing it as a module and it works fine. The problem is which way is better and when it is better, whether deploy it as any other application package or install it as a module?
(I noted that install it as a module is necessary for clustered environment. I am looking for, are there any other reasons?)
I think the correct link to the article you are referencing is this one : http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/
(The other one does not seem to point to the article you are mentioning)
Below is the interesting part from "Migrating The Database Connection" section you are referencing:
On WildFly, you have two ways of installing the JDBC driver: whether
you deploy it as any other application package or you install it as a
module. You can always choose to deploy the driver, but it’s specially
recommend when you have a cluster environment, since the deployments
are automatically propagated in the server groups.
You may have issues with the deployment if the driver is not
JDBC4-compliant. In this case, installing the driver as a module
solves those issues. The advantage of the JDBC driver as a module is
the possibility of creating a custom WildFly bundle for your
organization. This way, you can repeat exactly the same installation
throughout several machines, preserving the same configuration. This
is perfect for the development environment.
So in this section, the author describes the following advantage:
You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues.
The following Wildfly documentation describes this also:
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways. (...)
Thus, deploying your driver as a module is easier than deploying it as any other application package in case it is not JDBC-4 compliant. (Because you would have to modify and rebuild your JDBC-4 not compliant jar to deploy it as any other application package)
I am trying to understand the difference between XA vs Non XA JDBC datasource. Also how do I know which type and version of JDBC dtriver is used. I am currently on 10.3 weblogic and trying some tet to kill long running queries using setQueryTimeout, which isnt seem to be reliable with OracleXADataSource as it is only working the first time and not always.
Sorry for this basic question but I am new to Weblogic Datasource configuration
Thanks
XA jdbc drivers are used to implement two-phase commit, meaning the two remote resources are part of the same transaction. Java specifies an implementation of this via JTA. A good reading is e.g. http://www.javaworld.com/javaworld/jw-07-2000/jw-0714-transaction.html; if you google for 'xa jdbc driver' you'll find plenty more info.
You should not use the XA driver if not necessary. I remember reading that there are some problems with them.
To identify JDBC driver your WLS is using, go to the <domain_dir>/config/jdbc and open the data souce file, check the driver-name value in the file.
To identify the Driver version, check from which .jar is the driver being loaded (run the WLS with -verbose:class)- the name of the jar will contain the version number. Also, you can use java -jar my-jdbc-file.jar which will print the driver version. The OJDBC drivers are usually stored in a file named ojdbc6.jar or ojdbc7.jar, etc.