Is it a correct understanding that queries run in two SQL windows in PL/SQL Developer are executed as two separate transactions? (I tend to conclude this based on the fact that the results of a modification query issued in one window are not reflected in the results of a SELECT query issued in another window). If this understanding is correct, what is the utility of that given that the two transactions share a single connection?
Two transactions cannot share a single connection. If each window is a separate transaction, each window would open a separate connection to the database. If you have two transactions, you have two sessions.
If you want to see whether the different windows are using different connections, you can run
select sys_context( 'USERENV', 'SID' ) from dual;
If you get the same result in both windows, you have a single connection and a single transaction. If you get different results, you have different connections.
"Session Mode" is configurable via the preference settings. The default is "Multi-Session", in which each window runs in its own session.
The other options are "Dual Session" (my preferred setting), in which all windows share one session while the schema browser, session monitor, compilations etc use a second session, or "Single Session" where the whole application uses a single session.
Related
We are using the websphere as application server and spring-data to access an oracle database.
If we call the start page on our application, different data and a lot of labels from three different frames are loaded parallely from the database.
Now, if we monitor the database while open the start page, different database sessions are opened and closed. However, three sessions (get labels) are kept open, but inactive.
I think three sessions, because I have three frames and they all load a lot of labels parallely.
Is there a functionality in websphere, spring-data or oracle that recognizes when a sql statement is often executed and keeps the session open?
Or do you know why the sessions is kept open?
WebSphere Application Server data sources support pooling of connections and caching of prepared statements. This is enabled by default. As long as your application is using the WebSphere Application Server data source (obtained via resource injection #Resource or JNDI lookup) and uses java.sql.PreparedStatement for your SQL commands, PreparedStatements will be kept in the cache and reused as needed. It isn't clear from your question if you want this behavior or if you want to avoid it. If you are looking to disable caching of all prepared statements, you can configure the statementCacheSize of the data source to 0. Alternately, if there are only specific prepared statements that you wish to avoid caching, you can programmatically set the JDBC poolability hint on them:
preparedStatement.setPoolable(false);
In my project, developers use a single instance of Connection instead of a connection pool on an Oracle 12c.
Using a pool is a common practice and Oracle itself documents it: http://docs.oracle.com/database/121/JJUCP/get_started.htm#JJUCP8120.
But JDBC 4.2 specification says:
13.1.1 Creating Statements
Each Connection object can create multiple Statement objects that may be used concurrently by the program.
Why using a pool of connections instead of a single connection, if it's possible to use statements to manage concurrency?
The Oracle Database Dev Team strongly discourages using a single Connection in multiple threads. That almost always causes problems. As a general rule we will not consider any problem report that does this.
A Connection can have multiple Statements and/or ResultSets open at one time but only one can execute at a time. Connections are strictly single threaded and blocking. We try to prevent multiple threads from accessing a Connection simultaneously but there are a few odd cases where it is possible. These are all but guaranteed to cause problems. (It is not practical to fix or prevent these cases mostly for performance reasons. Just don't share a single Connection across multiple threads.)
If a client connects to the database via a dedicated server connection then that database session will only serve that client . If the client connects to the database via shared server connection, then a given database session may serve multiple clients over its lifetime.
This is documented here.
Also, at any one point in time, a session can only execute one thing at a time. If that wasn't the case, then running things in parallel wouldn't spawn multiple other sessions!
A single connection cannot execute several statements concurrently.
Yes one connection can execute more that one statement. It will be the programmer to chose connection pooling setting or multiple statements when executing over more than one thread. Most databases in the market can handle multiple statements in one connection.
This is causing issues as our procedures use session based global temp tables; need that for good reason. The actions of one web client interferes with that of another. Why is the same Oracle session reused by a separate client.
There is connection pooling with Web logic in place. I have printed the following to confirm that indeed 2 clients are being assigned same oracle session.
SELECT SYS_CONTEXT ('USERENV', 'INSTANCE'),
SYS_CONTEXT ('USERENV', 'SID'),
SYS_CONTEXT ('USERENV', 'SESSIONID')
FROM DUAL;
How to ensure each client gets a different session (not HTTP session, but Oracle session)? Is this something at Weblogic level that needs to be modified?
If you're using connection pooling in the middle tier, then once your middle tier code closes a connection, it is returned to the pool and is available to be used by another middle tier session. If you are trying to use global temporary tables that store data past the point that the middle tier closes a connection, you're doing something wrong.
You could design and build your middle tier so that it doesn't use connection pooling and so that each middle tier session opens a private database connection that is used only by that user. That would generally be a horrible idea, however, since you would generally end up spending oodles of time opening and closing database connections, you'd end up with thousands of orphaned database connections when an application user simply navigates away from the site rather than explicitly logging out, and it would become very difficult to do things like have the same user serviced by different app servers at different points in time for load balancing purposes.
A better approach would be to get rid of the global temporary table and store whatever data you need in a permanent table that includes your unique session ID as part of the key. You'd need to write code to purge the data at some point but that shouldn't be terribly difficult.
I am experiencing very low performance in my web application in which trivial HTTP requests take dozens of seconds to be processed. Tracing down the application code I discovered the majority of time is spent executing the first DB query, even if it is as simple as a SELECT on a single row-single column table. This happens for every HTTP request, independently from the query performed. After this first pathological DB interaction the remaining queries go smoothly.
I am using Hibernate on top of an Oracle DB (using jdbc).
It is not a problem of connection pool since I am successfully using Hibernate-c3p0, neither it seems to be related to Oracle itself, because all query returns immediately if performed directly on DB.
Furthermore, Hibernate SessionFactory is correctly created only once, at application start up time and concurrency is not a problem at all since tests have been done with single user.
Finally, my DB IP address is correctly resolved in my application server /etc/hosts so that even DNS related issues can be discarded (I am using two distinct virtual machines, DB and APP server).
I do not know what to look for, any help?
This sounds like your session factory object is being spun up on the first query. Generally I try to initialize the session factory on application startup to avoid this when issuing the first query because generally the user can see this slowdown. When doing it up front in application startup you will avoid this.
I need to have multiple logins and query executions into an Oracle db, 10 users per process, 10 processes per PC.
I was thinking that I would create 10 threads, one thread per user login.
Is this feasible? Any advice is appreciated.
Very new to threads.
Update:
Thanks for all the comments and answers.
Here are some additional details:
Using Oracle 10.2, Delphi XE, and dbExpress components created on the fly.
Our design is to run 10 processes per machine and simulate 10 user-logins per process. Each login is within its own thread (actually I need to have two logins in each thread, so I am actually creating 200 sessions per machine).
For this simulation exercise, after establishing a connection, each thread retrieves a bunch of data by calling several stored procedures within a loop. For each stored procedure I create a TSQLProcedure object on the fly and close and then free it after using it. Now I am getting ORA1000 Max Cursors exceeded, which I don't understand since I close and free each sp object.
Changing the settings on the server side is out of the question. I saw some documentation that says that on the application side you can set RELEASE_CURSOR=YES. I am guessing that it's an option set at the procedure level.
Yes, it is feasible. You may need a thread for each session you need (see here for an explanation), and you have to ensure OCI is called in a thread safe way, how to do it depends on the library you use to call OCI, if you don't call OCI directly.
Yes it is feasible. Remember that the UI runs on its own thread and can't be accessed directly by the other threads. Also remember you can't share state between threads unless you secure it. This is a start. Here an example on using threads with databases and the dbGo library. I suggest you give it a try and come back if you have specific questions.