I know ESRI do not longer distribute the Java-files needed so that Geotools can be used as before. But are there any workaround to use GeoTools or similar library using Direct-connect for versions after 10.3?
Its a bit hard to understand the documentation that only describes that the ArcSDE Connection supports version 10. There is no comment on changes in support from ESRI libraries.
The documentation indicates that you can get the required jars by requesting them from ESRI.
As for version 10.0, ArcSDE is part of the ESRI ArcGIS Server stack, and you may need to request a separate media DVD to ESRI for the ArcSDE Java SDK as it seems it doesn’t come with the standard DVD set but you can get it by just asking for it.
There is also a section on using Direct Connection
ESRI Direct Connect allows clients to directly connect to an SDE GEODB 9.2+ without a need of an SDE server instance, and is recommended for high availability environments, as it removes the ArcSDE gateway server as a single point of failure. ESRI DC needs additional platform dependent binary drivers and a working Oracle Client ENVIRONMENT (if connecting to an ORACLE DB). See Properties of a direct connection to an ArcSDE geodatabase in the ESRI ArcSDE documentation for more information on Direct Connect, and Setting up clients for a direct connection for information about connecting to the different databases supported by ArcSDE.
The GeoTools ArcSDE configuration parameters are the same as in the Configuration Parameters section above, with a couple differences in how to format the parameters:
server: In ESRI Direct Connect Mode a value must be given or the Direct Connect Driver will throw an error, so just put a ‘none’ there - any String will work!
port: In ESRI Direct Connect Mode the port has a String representation: sde:oracle10g, sde:oracle11g:/:test, etc. For further information check ArcSDE connection syntax at the official ArcSDE documentation from ESRI.
instance: In ESRI Direct Connect Mode a value must be given or the Direct Connect Driver will throw an error, so just put a ‘none’ there - any String will work!
user: The username to authenticate with the geo database.
password: The password associated with the above username for authentication with the geo database.
If you have tried these two approaches and still have an issue please ask a further question or clarify this one.
I see the documentation is quite unclear when it comes to what versions that are really supported.
We can connect to ArcSDE version 10.2 and earlier using ESRI libraries.
My question relates to ArcSDE versions post 10.3. Connections seems not possible on later versions.
Has anyone succeded Connecting to ArcSDE on versions post 10.3?
Related
Google Cloud SQL (MySQL) supports SSL Client Certificates for securing connections. I have gotten these working with the mysql CLI client and with MySQL-python without any drama, but Java's JDBC driver model seems to be significantly less flexible. I was able to get it working by importing the necessary keys and certificates into my keystore, but it does not appear that I can easily provide a specific certificate to use for a particular connection at runtime.
For my use storing all the certificates in a single keystore per JVM won't work, we have a multi-tenant environment with dozens of isolated client certificates. The PostgreSQL JDBC documentation offhandedly mentions it should be possible by implementing your own SSLSocketFactory (source):
Information on how to actually implement such a class is beyond the scope of this documentation. Places to look for help are the JSSE Reference Guide and the source to the NonValidatingFactory provided by the JDBC driver.
The Java SSL API is not very well known to the JDBC driver developers and we would be interested in any interesting and generally useful extensions that you have implemented using this mechanism. Specifically it would be nice to be able to provide client certificates to be validated by the server.
The only implementation I have seen is GoogleCloudPlatform/cloud-sql-mysql-socket-factory which on-the-fly queries the Google Cloud APIs to retreive emphemeral ssl client certificates. This is what I'm starting with, but I'm disheartened by the fact some basic socket properties (notably connectTimeout and socketTimeout) are not currently implemented.
Are there other SSLSocketFactory implementations I should be aware of? It seems like a generic implementation would be useful for multiple JDBC drivers (MySQL connector/J, PostgreSQL pgJDBC and Oracle offer some client cert support). That way JDBC connection strings could support client certificates as standardize parameters (base64 encoded?) just as usernames and passwords are currently included.
We are experiencing the issue when trying to connect to the cluster after updating the version of Java SDK.
The setup of the system is as follows:
We have a web application that is using Java SDK and a Couchbase cluster. In between we have a VIP (Virtual IP Address). We realise that isn’t ideal but we’re not able to change that immediately since VIP was mandated by Tech Ops. VIP is basically only there to reroute the initial request on application startup. That way we can make modifications on the cluster and ensure that when application starts it can find the cluster regardless of the actual nodes in the cluster and their IPs.
Prior to the issue we used JAVA SDK version 1.4.4. Our application would start and Java SDK would initiate a request on port 8091 to VIP. Please note that port 8091 is the only port open on VIP. VIP would reroute the request to one of the node cluster currently in use the cluster would respond to Java SDK. At that point Java SDK would discover all the nodes in the cluster and application would run fine. During up time if we would add, remove a node from the cluster Java SDK would update automatically and everything would run without the issue.
In the last sprint we updated the Java SDK to version 2.1.3. Our application would start and Java SDK would initiate a request on port 11210 to VIP. Since this port is not open the request would fail and Java SDK would throw an exception:
Caused by: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.couchbase.client.java.util.Blocking.blockForSingle(Blocking.java:93)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:108)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:99)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:89)
No further request would be made on any port.
It appears the order in which port are being used has been changed between versions. Could somebody please confirm, or dispute, that the order in which ports are being used for cluster discovery has been changed between versions. Also could somebody please provide some advice on how we could resolve the issue. We are trying to understand the clients behavior, if we could open all those ports on the VIP would the client still then function correctly and at full performance?
The issue is happening on our production environment which we cannot use for testing out potential solutions since it will interfere with our products.
In v2.x of the Java SDK, it defaults to 11210 to get the cluster map to bootstrap the application. This is a huge improvement actually as now the map comes from the managed cache and not the cluster manager (8091). The SDK should use 8091 as a fall back if it cannot get the map on 11210 though. Regardless, you really want to get that map from 11210, trust me. It cleans up a lot of problems.
To resolve this long term and follow Couchbase best practices, upgrade to the Java 2.2.x SDK, get rid of the VIP entirely and go with a DNS SRV record instead. That gives you one DNS entry for the SDK connection object and you just manage the node list in DNS. It works great. I say SDK 2.2 as the DNS SRV record solution is fully supported there, in 2.1 it is experimental. VIPs are specifically recommended against by Couchbase these days. In older versions of the SDKs it was fine to do this and it helped with limiting the number of connections from the app to the DB nodes, but that is no longer necessary and can actually be a bad thing.
in addition to Kirk's long term answer (which I also advise you to follow), a shorter term solution may be to deactivate the 11210 bootstraping (carrier bootstrap) through the CouchbaseEnvironment by calling bootstrapCarrierEnabled(false) on the builder.
I don't guarantee that it'll work with a vIP even after that, but that may be worth a try if you're in a hurry.
I was reading the documentation from Google Cloud SQL and it recommends that I have to use the MySQL original driver to connect to Google Cloud SQL from a external application.
I am currently using the cloud_sql.jar driver (old driver) for a external application.
Do you think I have to replace the cloud_sql.jar driver to the original driver (Connector/J)
Thanks.
Yes, please stop using the old driver and switch to Connector/J. Note that you will need to request and IP for the Cloud SQL instance and add the network you are connecting from to the list of authorized networks.
Reference: https://developers.google.com/cloud-sql/docs/access-control#appaccess
I have a C application using the MySQL library for database access.
Is there a standard way to implement database connection pooling for such an application?
The C connector doesn't appear to support it.
The Zild Database Library, "a thread-safe high level multi-database connection pool library", looks very promising.
Previously I suggested that
SQL Relay could be used to do this, amongst many other useful things, such as
client-side caching
load-balancing across database instances
translating between different database access APIs
If the MySQL library is dynamically linked this can be done without recompiling the application.
When I last looked in 2009, the mailing list suggested SQL Relay might not be fully ready for production use, but that appears to have changed.
We are developing an order taking system in PDA using C# in .netcf 2.0. So we are having mysql server as our back end. Is that the web service is the only way to connect mysql with PDA? Or is any other methods available..?
There is a .netcf connector on MySql web site available for download.
I recommend to use version 5.2.7 and not to forget to put "pooling=false" into the connection string, otherwise connection will fail with exception "MissingManifestResourceException" .
Connection string example:
"Persist Security Info=False;database=DATABASE_NAME;server=SERVER_IP_ADDRESS;user id=USERNAME_TO_LOGON;Password=PASSWORD;pooling=false"
I don't believe there is a Data Provider for MySQL in Compact Framework.
I recommend that you read the Mobile Application Architecture Guide, especially the Data Layer chapter to see what your options are.