Re: [REQ] Memory flag or way to monitor DB(dis)connections

Question

Presumably on Mon, 20 Jul 1998 17:29:29 +0200 Jean-Paul wrote:
[snip]
We're currently running an application with some DBSession Service Objects.
As in both code and partition workshop the parameter 'password' is hidden
(replaced with ***), we can't be really sure of what they contain.
Is there any flag or simple way to have every DB connection logged ?
[snip]
Jean-Paul
Be aware that the password is exported as PLAIN TEXT in the workspace export!
Since there is no code management system in Forte to keep track of versions/changes we have three different environments exporting the entire workspace form dev to test and then from test to live.
As part of the move we change the password string in the export file before moving from test to live - or so the theory goes.
If you want to monitor access to the database why not do so at the database level? BTW, what DB do you use?
Or if you need to keep track of DB access from the application write a little logger routine that writes a line to a central log file reporting whenever the DB access method(s) are accessed. Potential for significant overhead here. Of cause you have to ensure that only the say your designated EntityManager projects are allowed to access your database in the first place.
Dirk
Hobart TAS, part of sunny OZ (trust me they said)
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

Hmm.
Thanks for this answer.
I should have clarified that I wanted to know what they contained at runtime,
because we don't use hardcoded values (that any pex or wex would show as you spotted),
but environment variable names which values set at runtime depend on the launcher used.
(Actually, that's the only way to be portable in both development, test and live environments).
Therefore, as described below, I'm just looking for any sqlnet call or oracle instance connection
traceability.
I " use " oracle 7.X
To clarify, Fort&eacute; as a set of 'DB*' flags, one of them (we have) being able to trace any SQL call.
The idea was to 'add' the connection string used (i.e. to try to understand the 'too many processes'
oracle errors found, whether instance is accessed ; or to monitor the 'please use SQLNET V2' errors).
Any idea on " ultimate Memory Flags idiot's guide " welcomed.
Here's our situation :
All is plain text as you spotted. We use environment variable names in those fields,
substituted at 'launch' time with memory contents.
The idea would be to actually see at runtimethe database connection stringn something like :.
DATABASE CONNECTION
Caller : Ultimate_XZone_Tetris_Server_Cl34_part32 Partition
Object : DBSession UnexpectedUserStatsDBSO attached to instance Orcl
with connection string TetrisGURU/MyNameIsBond@Orcl)
Knowing that the code relies on those 'service object properties' :
External Manager : TetrisDBMgr
Database Name : ${TetrisDBNameString}
User Name : ${TetrisUserNameString}
User Password : ${TetrisUserPasswordString}
and the node manager running XXX_Ultimate_Application_Tetris_Server_Cl34_part32 has
the three environment variables set as public (i.e. exported to child processes).
Note : Of course we use uppercase variable names (unix :) ) and don't program tetris.
Thanks for any idea,
J-Paul
De: Dirk Haben[SMTP:[email protected]]
Date d'envoi: mercredi 22 juillet 1998 04:22
A: [email protected]
Cc: Forte-Users Soapbox
Objet: Re: [REQ] Memory flag or way to monitor DB (dis)connections
Presumably on Mon, 20 Jul 1998 17:29:29 +0200 Jean-Paul wrote:
[snip]
We're currently running an application with some DBSession Service Objects.
As in both code and partition workshop the parameter 'password' is hidden
(replaced with ***), we can't be really sure of what they contain.
Is there any flag or simple way to have every DB connection logged ?
[snip]
Jean-Paul
Be aware that the password is exported as PLAIN TEXT in the workspace export!
Since there is no code management system in Forte to keep track of versions/changes we have three different environments exporting the entire workspace form dev to test and then from test to live.
As part of the move we change the password string in the export file before moving from test to live - or so the theory goes.
If you want to monitor access to the database why not do so at the database level? BTW, what DB do you use?
Or if you need to keep track of DB access from the application write a little logger routine that writes a line to a central log file reporting whenever the DB access method(s) are accessed. Potential for significant overhead here. Of cause you have to ensure that only the say your designated EntityManager projects are allowed to access your database in the first place.
Dirk
Hobart TAS, part of sunny OZ (trust me they said)
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>