Allow Hostnames
|
Enter a comma separated list of hostnames
that can be used to access this workspace. If you leave
this attribute empty, the instance-level value applies.
If you enter one or more hostnames, the incoming HTTP
request URL's hostname part must match one of the listed
hostnames.
For example, you can register the DNS alias
hr.example.com for your web server
www.example.com . If you set the HR
workspace's Allow Hostnames to
hr.example.com , users have to
access HR applications using
hr.example.com and all other
applications of this instance
usingwww.example.com . With this
configuration, the browser's Same
Origin security policy provides a client-side
barrier between HR applications and other applications
of the instance, which run in another browser tab or
window.
If your workspace uses RESTful services, you
have to additionally configure a pool in the
url-mapping.xml configuration file
of Oracle REST Data Services for isolation. Note that
Oracle REST Data Services will ignore the
RESTful Path Prefix workspace
attribute if Allow Hostnames is
configured.
The configuration example below specifies
that RESTful services of the HR workspace can only be
accessed using
https://hr.example.com/apex/resource-handler :
<pool
base-url="https://hr.example.com/apex" name="apex"
workspace-id="hr" />
|
Resource Consumer
Group |
Specify the Database Resource Manager
consumer group to be used for all page events associated
with this workspace. If you leave this attribute empty,
the instance level value applies. The Resource Consumer
Group provides more control of hardware resources such
as CPU and I/O requests. Workspace-level settings
override instance-level settings to enable
administrators to provide more or less resources
depending on the needs or importance of a workspace.
At the beginning of every request, the APEX engine switches the current consumer group of the
current database session to the consumer group that is
defined at workspace or instance-level. This applies to
both executing applications and any of the applications
used within the APEX development environment.
These limitations apply to all page
requests, where application code executes using the APEX engine which enables the assigned Resource Manager
settings. However, they do not apply to Oracle Scheduler
jobs that workspace developers create, or to ORDS REST
requests where APEX is not in the code path.
A call to set the workspace, such as
apex_util.set_workspace('MY_WORKSPACE');
at the beginning of the scheduler job, enables the right
consumer group. However, there is often no reason for
developers to add this type call. Therefore,
administrators should apply the Resource Manager
consumer groups both to APEX workspaces and to the workspace schemas (that is, the
underlying database users).
You must grant privilege to switch to a
consumer group to either PUBLIC or the
APEX schema. This privilege is typically granted using the
procedure
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP .
See Also: Managing
Resources with Oracle Database Resource
Manager in Oracle Database
Administrator’s Guide
|
Maximum
Concurrent Workspace Requests |
Enter the maximum number of concurrent page
events that APEX supports for all applications of this workspace. If
you leave this attribute empty, the instance-level value
applies. Instead of processing a page event, APEX shows an error message when the limit is already
reached.
APEX keeps track of session requests by querying the
CLIENT_INFO column of
GV$SESSION . This tracking will not
work if developers overwrite
CLIENT_INFO , for example, with a
call to
DBMS_APPLICATION_INFO.SET_CLIENT_INFO .
|
Maximum
Concurrent Session Requests |
Enter the maximum number of concurrent page
events that APEX supports for each session for applications in this
workspace. Instead of processing a new page event, APEX shows an error message when the limit is already
reached. Alternatively, use the Concurrent Session
Requests Kill Timeout attribute to kill an active
database session, to process the new page event.
APEX keeps track of session requests by querying the
CLIENT_IDENTIFIER column of
GV$SESSION . This tracking will not
work if developers overwrite
CLIENT_IDENTIFIER , for example with
a call to
DBMS_SESSION.SET_IDENTIFIER .
|
Concurrent
Session Requests Kill Timeout |
If a new page event comes in that is outside
the limits of Maximum Concurrent Session
Requests, APEX can execute alter system kill
session on the oldest active database
session which processes another page event for this APEX session. This attribute specifies the number of
seconds a database process has to be active, before it
can be killed. If you leave this attribute empty, the
instance-level value applies.
Warning: Killing sessions can cause
problems with the application server's database session
pool.
|
Maximum Size of
Files in Workspace |
Enter the total size (in bytes) of all files
that can be uploaded to this workspace.
|
Maximum Email
Messages |
Enter the maximum number of email messages
that can be sent with the APEX_MAIL API
per 24 hour period.
This value overrides the instance-level
setting.
|
Maximum Web
Service Requests |
Enter the maximum number of email messages
that can be sent with the APEX_MAIL API
per 24 hour period. This value will override the
instance-level setting.
|
Content Cache
target size |
Denotes the target size for the content cache
on workspace-level. The content cache can currently
being used by Web Source and REST Enabled SQL services.
The Cache Size Target acts as a soft limit, which, for
performance reasons, is only maintained by the APEX scheduler jobs. In other words, APEX might exceed the specified limit during normal
operations. With the next run of the maintenance job,
cached content with the shortest remaining validity will
be removed until the cache size is below the specified
limit.
|
Content Cache
maximum entry size |
Denotes the maximum size for content to be
placed into the content cache. This value will override
the instance-level setting.
This value overrides the instance-level
setting.
|
Maximum Background
Page Process Jobs |
Specifies the maximum amount of scheduler
jobs being available for background execution of page
processes for this workspace (applies to all
applications). Only the configured amount of jobs will
run at the same time to execute page processes in the
background. If the configured maximum amount of
scheduler jobs is active, new submitted executions will
wait until a job becomes available.
See Also: "Configuring Limits for
Concurrently Running Scheduler Jobs" section in About
Background Page Processes in Oracle APEX App Builder
User’s Guide
|