I have an application and those user accounts are application users,
not database users, i.e. userid and password stored on the user table
(e..g usr_user).

Now, I would like to check with any multiple login of users (same
machine or another user) and in case having, the application will warn
the user and not allow further login.

Currently, I think of checking with V$session. But then, may need to
set the value of user id when user logins to the application.

Is it possbile and any information can be shared?

On Sep 21, 4:50*am, Mullin Yu <mullin... (AT) gmail (DOT) com> wrote:
How do you plan to use v$session when the users are logging on via an
application user and so all have the same Oracle username? Does the
application use dbms_application_info to inform Oracle of the real end
user? Does the application use connection pooling?

If you can modify the applicaiton code it should be fairly easy via
the application to track logon's/user sessions.

Perhaps you can explain what you want a little more clearly.

HTH -- Mark D Powell --

On Tue, 21 Sep 2010 01:50:40 -0700, Mullin Yu wrote:

You can use resource limits and set sessions_per_user in create/alter
profile statement.



--
http://mgogala.byethost5.com

On Sep 21, 1:50*am, Mullin Yu <mullin... (AT) gmail (DOT) com> wrote:
Why do you want to do this? For most apps I've seen, people love
being able to have multiple windows on their display. Sometimes it
can be a PITA if you have special serialization requirements, I have a
job barcoding time-series app like that which is very touchy about
commits, but even so, there are other session variables available to
limit what really needs to be limited.

Normally when I hear a request like this there is either some serious
misapprehension of multiuser capabilities, or people are worried about
the wrong security issues.

jg
--
@home.com is bogus.
"45 minutes 'til I go onstage at Moscone West L2 2014: Messed-Up Apps
(3pm). Plz join me. " - Cary Millsap

1. can't use sessions_per_user as those users are application users,
not database users. that FAT client uses the same common database
account to make connection to database.

2. it's for security concern to have that requirement

3. expect to use "dbms_application_info" to set CLIENT_INFO with real
application user id.

just wonder if the FAT client quits gracefully or accidentally, will
the session/record in V$Session be cleaned up at once as it's what i
assume for this mechanism. if not, this approach may not be working.


On Sep 22, 12:22*am, joel garry <joel-ga... (AT) home (DOT) com> wrote:

On 09/21/2010 05:06 PM, Mladen Gogala wrote:
Not if I understand "application users" correctly: there will
be only one account that actually connects (application_owner)
and all standard security is ignored.
There will be only one user session.

Your approach is valid when combined with proxy users. Still
one application owner user from the middle tier...

--

Regards,

Frank van Bortel

On 09/22/2010 03:42 AM, Mullin Yu wrote:
Sounds like security by obscurity. No more than two sessions...


Check SQLNET.EXPIRE_TIME:
"Setting a value greater than 0 ensures that connections are not left
open indefinitely, due to an abnormal client termination. If the probe
finds a terminated connection, or a connection that is no longer in use,
it returns an error, causing the server process to exit. This setting is
intended for the database server, which typically handles multiple
connections at any one time."

--

Regards,

Frank van Bortel

On Wed, 22 Sep 2010 09:10:15 +0200, Frank van Bortel wrote:

One session to rule them all? Hmmm, the solution involves an active
volcano, big spiders and a lot of drama.



--
http://mgogala.byethost5.com

On Sep 22, 3:10*am, Frank van Bortel <fbor... (AT) home (DOT) nl> wrote:
I think "There will be only one user session" should be stated more
like "to the database there will be only one Oracle username in use
which will be used to open multiple Oracle sessions for the
application"

Using dbms_application_info to identify the real end user for the
session may or may not be an option depending on if connection pooling
is in use. When connection pooling is in use then since every SQL
statement issued by a user can be assigned to any open pooled session
then dbms_application_info is no longer reliable for this purpose.

HTH -- Mark D Powell --