I have a docker container with Oracle DB which I try to access from different clients with same credentials and its behaviour is quite strange.
I have set up connection in IDEA with following JDBC URL: jdbc:oracle:thin:#//localhost:1526/XEPDB1
Also I work with it via Spring Data framework in another container, url is jdbc:oracle:thin:#oracle:1521/XEPDB1 (port is forwarded to outer world as 1526, container name is oracle)
And finally, I tried to access the db using sqlplus from within db host: sqlplus LOGIN/PASSWORD#localhost:1521/XEPDB1
All connections are successful, but simple inserts and selects for same table show that each client sees only it's own modifications. What is wrong? How do I share same table between clients?
According to the connection strings, all the users are connected to the same database, so that isn't the issue.
The issue is probably that each user that modifies the data (e.g., inserts new rows), does so without committing, and thus this data is only available in their current session. Once they commit the data, it will be available to all the other sessions too.
Related
I have a problem with our production database.
CDC in activated in our MSSQL database, both in test and production. But as long as new records store in the test database we receive captured records in our Kafka topic but in the production area, there are no results.
I have a user in the production server with exact same config and properties with
which I have in the test server.
Both with public and db_datareader user mapping in login properties.
But there is a slight bit of differentiation when I execute the query
EXEC sp_cdc_help_change_data_capture
According to this Debezium documentation, I should get a result back showing
tables with corresponding CDC capture configurations. So, it returns mentioned result in the test database but I don't get back anything (empty result) in the production database.
Are there any additional settings that I should consider to get appropriate results?
I've started the HSQLDB server with two databases open. i'm using the server protocol for connection i.e.
jdbc:hsqldb:hsql://localhost/portdb
portdb is just one database, how can i tweak this URL such that it connects to this and the other db?
I've been referring to hsql user guide but seems nowhere defines this
You cannot open or connect to two databases with the same java.sql.Connection. Use two different connections, each with its URL.
You can have multiple schemas inside a database and access them with a single connection. See http://hsqldb.org/doc/2.0/guide/databaseobjects-chapt.html
My requirement is to retrieve data from a local SQL server and store that data in remote server. I would like to get the data from the local SQL Server and use that data in my application to proceed further.
Yes, see Create linked server with SQL command.
You can create the linked server either locally (I'd recommend that) or remotely
If you mean you want your remote server to execute queries on the local one then yes, but...
Setting this up is a fair bit of work and if I remember rightly needs a hefty amount of privileges on the remote server.
Might be easier to set up the linked server locally. NB assumes the account the local server is running as can reach the remote machine, and can access it.
I'd be a bit nervous about doing this, internally for fear of some admin type breaking it, if it's over the internet, then securing it will be a nightmare even if they allowed their server to be accessed directly..
You might find it easier to do it via the client, though that will dpend on how much data you want to synchronise, and then perhaps a briefcase approach might do the job better.
You can set up linked servers either via the GUI in SSMS, or via scripts. A couple of things to look out for though - first make sure you create a login account on each server that is mapped to the appropriate database on each server, with the least possible permissions. Then verify the mapping after you've set it up. Be aware that you are opening up the attack surface via this solution, so you may want to have your admin set up auditing too.
Is it possible to have SQL Server create a temp table inside a particular database upon a user connecting to the database in such a way that the connecting user is the only one with access to the contents in this table (or even better, the connecting user is the only one that can even see the table)?
I tried using a logon trigger (including using a 'with execute as caller' clause) but although this creates the temp table, the connecting user can never see it/select from it.
All of this has to run inside SQL Server and require no user interaction at all...
Basically, this is the scenario I want to support:
user connects
a temp table is created inside a particular DB inside SQL (by SQL, kicked off by establishing of the connection)
some specific information is populated inside the table
for the duration of the connection; the user has (Read) access to the contents in this table; the information in this table is used by a sub-system inside a particular database
user disconnects
the temp table and all its contents is dropped by SQL
Thanks
First thoughts:
modify your client code to create the table on connection? Then it can be done only when needed not all the time
use a common, persisted table with a SessionID based on a GUID? This will provide some audit + troubleshooting information too
use table value parameters to send data on demand rather than have any server-side caching
And what I'd probably do:
create the table when it's populated when I need it. The user can connect to the database for a variety of reasons (I assume). So "connection" should be decoupled from "CREATE TABLE".
Using temp tables for this would not be the right approach if your data access is properly designed to open a connection-do an operation/query-close the connection. The moment you closed the connection, the temp table would be destroyed. It would be better to use a view or stored procedure to filter the information to which the user should have access. The structure of that view will depend greatly on how users connect to the database. Do users connect to the database using their own personal windows authentication account or do they connect indirectly through another account like many web servers do?
IMO, the better approach is the second bullet point of gbn's answer: a common persisted table with an indicator as to the session or user.
I have an application that is deployed on tomcat on server A and sends queries to a huge variety of SQL Server databases on an server B.
I am concerned that my application could overload this SQL Server database server and would like some way to preventing it making requests to connect to any database on that server if some arbitrary number of connections were already in existence and unclosed.
I am looking at using connection pooling but am under the impression that this will only pool connections to a specific database on the SQL Server server, I want to control the total of these combined connections that will occur to many different databases (incidentally I can only find out the names of individual db's dynamically as they change day to day). Will connection pooling take care of this for me, are am I looking at this from the wrong perspective?
I have no access to the configuration of the SQL Server server.
Links to tutorials or working examples of your suggested solution are most welcome!
Have you considered using DBCP? See here for more info
You're correct. A database pool will limit connections to either the database, or to all databases, depending on how the pool is configured.
Here are several open source packages that implement database connection pools. One of them probably does what you want.
connection pooling ... this will only pool connections to a specific database on the mssql server
AFAIK, this is correct. Your connection pool will only limit the number of connections to the specific database it is defined for.
want to control the total of these combined connections that will occur to many different databases
I dont think you can control the number of connections to all databases from the pool. You've written you don't have access to change things on the MSSQL server. so creating SYNONYMs to the various databases on MSSQL itself is not an option.
You can write your own class within the application, say a ConnPoolManager, which has an internal counter prior to getting and releasing Connections from any of the pools.
This class should cache all the JNDI lookups to each pool.
For the app to get a connection to ANY pool, it goes through the ConnPoolManager and if the counter shows the maxlimit is not yet crossed, only then does it fetch the connection.
Else it throws some exception for you to try later.
There might be a design pattern for this on the lines of Business Delegate.
Having said that, I think a bigger problem for you will be
incidentally I can only find out the names of individual db's dynamically as they change day to day
since you will be expected to create new or edit the connection pool settings in Tomcat each day? This is a maintenance nightmare in the future.