27 Ago 2025 Integrating Oracle Fusion ATP with mTLS using a Databricks Shared Cluster

In enterprise data architectures, integrating operational systems with big data platforms is essential for unlocking meaningful insights, and when this integration extends across public cloud environments the task becomes more challenging. Recently, while working with one of our customers, we faced exactly this scenario: connecting Oracle Fusion’s Autonomous Transaction Processing (ATP) database directly with Databricks, using a shared cluster.

Although wallet-based connectivity to ATP is well documented, running it in a distributed environment like Databricks presented some unexpected hurdles. In this blog post we’ll share how we implemented the integration, the issues we encountered, and the solution we developed to overcome them.

Oracle Fusion and ATP

Oracle Fusion Applications are a suite of enterprise resource planning (ERP), human capital management (HCM), and customer relationship management (CRM) cloud solutions designed to help organisations to manage core business processes. Behind the scenes, these applications store operational and transactional data in Oracle ATP, which is a self-driving, self-securing, and self-repairing database optimised for fast query performance and real-time analytics. For both data engineers and analysts, integrating ATP with modern platforms like Databricks is vital to enable scalable reporting, advanced analytics, and AI-driven insights across enterprise data.

Connecting to ATP via Wallet Authentication

In enterprise environments, Oracle ATP instances must follow the highest security standards, and one of its security enablers is the wallet. An Oracle Wallet is a secure container used to store the authentication and configuration credentials required for secure communication between clients and Oracle Autonomous Databases. Specifically, when using mutual TLS (mTLS), the wallet contains certificates, truststores, and network configuration files, such as tnsnames.ora, needed to establish encrypted JDBC (Java Database Connectivity) connections. Typically delivered as a ZIP file via the Oracle Cloud Console, it enables applications such as Databricks to authenticate and connect securely to ATP instances.

The blog post Connect Databricks to Oracle Autonomous Database using mTLS provides an excellent starting point for basic integration, especially for single-node clusters. However, replicating the solution using a shared cluster did not work as expected, and we needed additional configuration to ensure that all nodes, especially executors, could access the wallet files.

Why the Wallet Approach Fails on Shared Clusters

Initially, we followed these standard steps:

1. Get the ATP wallet ZIP file from the infrastructure team.
2. Upload it to a volume in Databricks.
3. Unzip it into a mounted volume accessible to the cluster, using a script.
4. Use the JDBC connector with oracle.net.wallet_location pointing to this path in a notebook.

Nevertheless, the integration failed at runtime with errors indicating the ATP database was rejecting our connection due to ACL filtering:

 
(java.sql.SQLException) Listener refused the connection with the following error:
ORA-12506, TNS:listener rejected connection based on service ACL filtering

At first, this error threw us off course as we believed it meant the Oracle ATP database was blocking the Databricks cluster IP because it hadn’t been whitelisted.

Once the Oracle team confirmed the IP was correctly whitelisted, our focus turned to why the ATP database wasn’t honouring it, which led to unnecessary effort for both teams.

One way we tried to narrow down the issue was by placing the wallet file on the local filesystem /tmp. This also produced the error, but we noticed something unusual: the dataframe had metadata fetched from the ATP database, but no data!

What Was Really Happening Behind the Scenes

We observed that metadata queries (such as schema introspection) were successful, and the dataframe contained the table columns but no rows. This indicated that Databricks was indeed able to reach the ATP database, but was failing to fetch the actual data.

We deduced that only the driver node was able to access the wallet successfully, but the executors, running on different nodes, could not resolve the volume path or lacked permissions to the mounted directory. After experimenting with various permissions and techniques to allow the executor nodes to access the file, we were able to confirm with the Databricks support team that in shared clusters, volume-mounted paths may not be consistently accessible across all nodes, particularly for executors. In this case, the Spark JDBC reader (spark.read.format(«jdbc»)) could not resolve the volume path. As a result, if the Oracle Wallet (e.g. cwallet.sso) is only available to the driver or a subset of nodes, the connection will fail.

The Working Solution

To get around this, we used a cluster-scoped init script to extract the wallet into the /tmp directory of each node at cluster startup, by following the steps below:

1. Get the ATP wallet ZIP file from the infrastructure team.
2. Upload the wallet ZIP file to a volume.
3. Create an init script that copies the wallet from the volume to /tmp and unzips it.
4. Attach the init script to the cluster.
5. Use the JDBC connector with oracle.net.wallet_location pointing to this path.

And voila! We were able to successfully integrate and fetch all required data directly into Databricks.

Key Takeaways

• Standard wallet connection methods may work on driver nodes but fail on executors in a distributed cluster.
• Placing the wallet in a volume only accessible to the driver can result in partial success (metadata fetches) but runtime query failures.
• Using an init script to unzip the wallet into a common path like /tmp ensures all nodes in the cluster have access.
• This approach is essential for shared clusters where Spark tasks are distributed across worker nodes.

Final Thoughts

If you’re integrating Oracle ATP with Databricks in a multi-node setup, it’s important to recognise the limitations of wallet accessibility. While the standard approach might work in single-node environments, shared clusters introduce complexities around executor access that can silently break your integration. Using cluster-scoped init scripts is a reliable and repeatable way to ensure consistent credential availability across all nodes, helping to avoid wasting time on misdiagnosed errors and incomplete data loads.

We’ve delivered multiple successful Databricks–Oracle integrations across a variety of enterprise environments. Our consultants not only troubleshoot issues like these but also design and implement scalable, secure, and future-proof data platforms tailored to your business needs.

If you’d like to learn more about this integration, or if you’re exploring broader use cases with Databricks and Oracle, our experts will be happy to help. Just contact our team or explore our other blog posts for more insights and practical guidance!