Oracle / JD Edwards
JD Edwards concurrent licensing. The peak count rule.
JD Edwards concurrent licensing counts the peak number of simultaneous sessions, not named users. The way you measure the peak decides what you pay.
JD Edwards concurrent licensing counts the peak number of simultaneous sessions, not named users. The way you measure the peak decides what you pay.
JD Edwards concurrent user licensing counts the peak number of simultaneous sessions, not named users. This guide covers the peak rule, the auditor view, the counting traps, and the renewal moves.
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
Concurrent licensing counts the highest number of sessions active at the same instant during a measured window. It is a peak, not an average and not a headcount. Two part time staff who never overlap can share one concurrent license. Oracle describes the product line on its JD Edwards EnterpriseOne page.
The measured window decides the result. A window over a busy month captures a higher peak than a window over a quiet one. Pick the window with care.
A session is a live connection to the application. The contract defines what counts. A user with two open sessions can count as two unless the metric says otherwise.
Read the exact metric wording in your order. The definition of concurrent and session differs by contract vintage. The applicable price list sits among the Oracle price lists.
The auditor pulls the session log and finds the highest concurrent count. Anything open at that instant counts, whether or not a human was using it. Oracle runs these reviews through License Management Services.
The log table records every active session over time. The auditor reads the maximum row. Dormant and parallel sessions sit in that table and lift the peak.
The auditor often samples a peak period rather than a steady week. A sample taken during quarter close can overstate the real business peak.
Concurrent suits estates where many people use the system but few use it at once. Named user suits estates where most users are active at the same time. The right metric depends on the access pattern and the wording in your Oracle agreement.
Concurrent versus named user
| Access pattern | Better metric | Why |
|---|---|---|
| Shift based or part time | Concurrent | Few users overlap at any instant |
| Most users active at once | Named user | Peak approaches the headcount |
| Seasonal spikes | Concurrent with tuning | Tuning controls the measured peak |
| Heavy integration load | Named user for system accounts | System sessions inflate the peak |
Tune session timeouts, close dormant sessions, and separate system accounts before measuring. A clean estate produces a defensible peak that reflects real business use.
The standard advice is to accept the auditor measured peak as the true requirement. We disagree. In roughly 6 of 10 estates we reviewed, timeout settings and uncleared system sessions inflated the peak by a double digit percentage above real business use. Accepting that number locks an overstated baseline into the renewal. The buyer side move is to tune timeouts, close dormant sessions, and separate integration accounts before any measurement, then present a clean peak. The auditor reads the log you give them, so the log you maintain is the negotiation.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The auditor does not count your users. The auditor counts your sessions. Clean the sessions and the peak follows.
Five moves recur in well run JD Edwards estates.
Concurrent licensing counts the highest number of sessions active at the same instant in a measured window. It is a peak, not a headcount, so users who never overlap can share a license.
Dormant sessions that never close, parallel sessions from one user, batch jobs, and system integration accounts all sit in the session log and lift the measured peak above real business use.
The auditor reads the session log table and takes the maximum concurrent row, often from a busy sample period. Anything open at that instant counts, whether or not a person was using it.
It depends on the access pattern. Concurrent is cheaper where many people use the system but few use it at once, such as shift based or part time estates. Named user is cheaper where most users are active together.
Yes. Shorter idle timeouts close dormant sessions before they are counted. Tuning timeouts commonly removes a double digit percentage from the measured peak.
Often yes. Scheduled jobs and integration accounts hold sessions while they run, and those sessions appear in the log. Separating system accounts from human users gives a cleaner human peak.
Measure a representative window after tuning timeouts and closing dormant sessions, not during a quarter close spike. A clean, documented baseline is your strongest renewal position.
Sometimes, through a contract change. The switch is worth modeling when your access pattern is shift based or part time, because the peak can sit well below the named user headcount.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
