Abstract
Your PLM knows exactly who every user is. It authenticates them, authorises them against a permission model, stamps their identity on every item they create and records their name in the change history.
Then it opens a database connection as a single service account and every one of those users arrives at SQL Server or Oracle wearing the same name.
Most of the time this is unremarkable and even good practice — connection pooling depends on it. It matters on the day something goes wrong at the database layer, because every diagnostic the database can give you is anonymous. A deadlock report names two sessions, both authenticated as the same login. A blocking chain names a head blocker you cannot trace to a person. A query consuming the server for ninety seconds belongs to nobody.
This is the attribution gap: identity is rich above the connection and absent below it and the gap falls exactly where production incidents are diagnosed. This paper explains why it exists, why the obvious fixes are worse than the problem and what actually recovers attribution.
1. Where the identity goes
The sequence is ordinary and the loss is structural.
A user signs in. The application authenticates them, resolves their identity and their group memberships and holds that context for the request. Business logic runs with full knowledge of who is acting. Then the data access layer needs a connection, takes one from a pool and issues SQL.
The pooled connection was opened under the application's service account, at startup, before that user existed as far as the database is concerned. It is shared, by design, because opening a connection per user would destroy throughput and exhaust the server. So the SQL arrives authenticated as the application, not as the person.
Everything the database records about that statement — the login name, the session, the host — describes the application tier. The user's identity was real and it stopped at the connection boundary.
This is not a flaw anyone introduced. It is the direct consequence of connection pooling, which is not optional at scale. Every multi-user application built this way has the same gap. It is simply more consequential in PLM than in most, because PLM holds long transactions, deep structures and heavy writes, which means it produces database-level incidents more often than a typical web application does.
2. The incidents where this hurts
Deadlocks. Two sessions take locks in opposite orders and the database kills one. The deadlock graph is generated, which sounds like good news. It names the two victims by login — the same login, twice. You can see the statements and the objects. You cannot see which two humans were doing what, which means you cannot ask them — and asking them is almost always the fastest route to the cause.
Blocking chains. One long transaction holds a lock and forty users stall behind it. You can identify the head blocker's session and its statement. You cannot identify the person to go and speak to and the usual resolution — kill the session — destroys the evidence along with the problem.
Resource-consuming queries. A query pattern is eating the server periodically. You can see the plan and the frequency. Without attribution you cannot tell whether it is one user running a legitimate but pathological report or an integration looping — and those have opposite remedies.
After-the-fact forensics. Something changed, the application audit does not cover it and the database is the only remaining source. It can tell you what happened and when. It cannot tell you who, which is the only part anyone wanted.
In each case the database gives a complete technical picture and withholds the one field that makes it actionable.
3. The fixes that look obvious and are worse
"Connect each user under their own database login." This recovers attribution perfectly and is almost always the wrong answer. It defeats connection pooling, so throughput collapses and connection counts explode. It requires provisioning and deprovisioning a database principal for every user, which is an administrative burden and a security surface in its own right. It duplicates your identity model into a second system that will drift from the first. A handful of applications genuinely need this. A PLM does not.
"Turn on full database auditing." This records statements, not people, so it produces far more data and the same anonymity. It also carries a real performance cost on a write-heavy system.
"Read the application log and correlate by timestamp." Reasonable instinct, and it works often enough to be tempting and fails often enough to be dangerous. Under concurrency — which is precisely the condition that produced the incident — multiple users act within the same second, clocks differ between tiers and the correlation becomes a guess. A guess presented as attribution is worse than admitting you do not know, because somebody will act on it.
4. What actually recovers attribution
The workable approach does not try to change who the connection belongs to. It carries identity inside the traffic so that the database's own diagnostics contain something that leads back to a person.
Put a correlating identifier into the SQL itself. Many PLM platforms already do half of this incidentally: the statements they generate contain the identifiers of the items being acted on. A deadlock report includes the input buffer — the actual statement text — so the item identifier travels into the diagnostic for free. And an item identifier is enough, because the application knows who was working on that item at that time. The identity is recovered by joining the database's evidence to the application's knowledge, using the object as the key rather than the clock.
That single observation is the practical core of this paper. In a system where every user shares one database login, the item identifier is the only reliable bridge back to the human — and in most PLM platforms it is already present in the statement text, waiting to be used.
Three further measures make this dependable rather than lucky:
Set a session context where the platform allows it. Some database engines let an application attach an application name, a client identifier or a session context value to a pooled connection for the duration of a request. Where that is available it is the cleanest mechanism, because the identity appears directly in the diagnostic rather than being inferred.
Capture deadlocks automatically, with the graph retained. Deadlock information is ephemeral. Without a capture mechanism the graph has usually aged out of the ring buffer by the time anybody investigates. You are left with a user complaining that something failed yesterday. A lightweight capture that writes the graph — including the input buffer — to a table costs almost nothing and is the difference between diagnosis and speculation.
Record the application-side context for the same window. Which users were acting on which items, at that time. This is the other half of the join and it is often already available from the platform's own history.
We have built exactly this on SQL Server: a real-time deadlock capture that retains the graph and resolves it back to the Aras user and item, in an air-gapped environment with no email path, specifically because the shared application login made every native report anonymous. The item identifier in the input buffer was the only viable bridge and it worked.
5. The design principle underneath
Step back and the attribution gap is one instance of a general rule worth stating on its own:
Identity must be carried deliberately across every tier boundary, because it is not carried automatically.
The application knows who. The database does not. The vault does not — which is the same gap in different clothing and the reason file download auditing is so much harder than change auditing. An integration's service account does not. Each boundary is a place where "who" is dropped unless somebody designed it to survive and nobody notices the loss until an incident requires the field that was discarded.
The remedy is the same in every case: decide what the bridging key is, make sure it is present on both sides of the boundary and make sure something durable records it. In PLM the item identifier is usually that key, because it is the one thing both tiers genuinely share.
6. Counter-arguments
"We have never had a deadlock." You have had deadlocks. The question is whether anyone connected the user-visible symptom — an operation that failed and succeeded on retry — to a database event. Most PLM deadlocks are invisible precisely because the application retries and the user shrugs.
"Our platform handles this." Verify it rather than assuming. The concrete test is in the next section and it takes an hour.
"This is the DBA's problem." It is a boundary problem, which means it belongs to nobody by default — and that is exactly why it persists. The DBA has the diagnostics and not the identity model. The PLM administrator has the identity model and not the diagnostics. Neither can close it alone.
"Cloud and SaaS make this moot." The opposite. On a managed platform you have less access to database diagnostics, not more, so the attribution has to be designed into the application layer or it is unavailable at any price.
7. The hour that tells you where you stand
- Deliberately cause a deadlock in a test environment — two sessions, two objects, opposite order. This is easy to arrange and worth doing.
- Go to the database's deadlock report. Can you name the two users? If both sessions carry the same login, you have the gap.
- Check whether the statement text contains an item identifier. If it does, you have your bridging key and the remaining work is capture plus a join.
- Check how long the diagnostic survives. If it has already aged out of the ring buffer, your real problem is capture rather than attribution.
- Ask who would investigate a blocking incident at 3pm on a Tuesday and whether they could name a person by 3.30pm.
Whatever you cannot answer in that hour is what you will not be able to answer during an actual incident, when the pressure is higher and the evidence is already expiring.
White paper. PLMClub implements on Aras Innovator and has built deadlock capture with user-and-item attribution on SQL Server, including in an air-gapped environment. The technique described in section 4 — recovering identity through the item identifier carried in the statement text — is drawn from that work. If your database incidents are anonymous and you would like them not to be, get in touch.