Server User Manual
Table Of Contents
- Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide
- Preface
- Overview of Enterprise Server Performance Tuning
- Tuning Your Application
- Java Programming Guidelines
- Java Server Page and Servlet Tuning
- EJB Performance Tuning
- Goals
- Monitoring EJB Components
- General Guidelines
- Using Local and Remote Interfaces
- Improving Performance of EJB Transactions
- Use Container-Managed Transactions
- Don’t Encompass User Input Time
- Identify Non-Transactional Methods
- Use TX_REQUIRED for Long Transaction Chains
- Use Lowest Cost Database Locking
- Use XA-Capable Data Sources Only When Needed
- Configure JDBC Resources as One-Phase Commit Resources
- Use the Least Expensive Transaction Attribute
- Using Special Techniques
- Tuning Tips for Specific Types of EJB Components
- JDBC and Database Access
- Tuning Message-Driven Beans
- Tuning the Enterprise Server
- Deployment Settings
- Logger Settings
- Web Container Settings
- EJB Container Settings
- Java Message Service Settings
- Transaction Service Settings
- HTTP Service Settings
- ORB Settings
- Thread Pool Settings
- Resources
- Tuning the Java Runtime System
- Tuning the Operating System and Platform
- Tuning for High-Availability
- Index

If the database runs out of device space, the HADB returns error codes 4593 or 4592 to the
Enterprise Server.
Note – See Sun Java System Application Server Error Message Reference for more information
on these error messages.
HADB also writes these error messages to history les. In this case, HADB blocks any client
requests to insert, or update data. However, it will accept delete operations.
HADB stores session states as binary data. It serializes the session state and stores it as a BLOB
(binary large object). It splits each BLOB into chunks of approximately 7KB each and stores
each chunk as a database row (context row is synonymous with tuple, or record) in pages of
16KB.
There is some small memory overhead for each row (approximately 30 bytes). With the most
compact allocation of rows (BLOB chunks), two rows are stored in a page. Internal
fragmentation can result in each page containing only one row. On average, 50% of each page
contains user data.
For availability in case of node failure, HADB always replicates user data. An HADB node stores
its own data, plus a copy of the data from its mirror node. Hence, all data is stored twice. Since
50% of the space on a node is user data (on average), and each node is mirrored, the data devices
must have space for at least four times the volume of the user data.
In the case of data refragmentation, HADB keeps both the old and the new versions of a table
while the refragmentation operation is running. All application requests are performed on the
old table while the new table is being created. Assuming that the database is primarily used for
one huge table containing BLOB data for session states, this means the device space
requirement must be multiplied by another factor of two. Consequently, if you add nodes to a
running database, and want to refragment the data to use all nodes, you must have eight times
the volume of user data available.
Additionally, you must also account for the device space that HADB reserves for its internal use
(four times that of the LogBufferSize). HADB uses this disk space for temporary storage of the
log buer during high load conditions.
Tuning Data Device Size
To increase the size of the HADB data devices, use the following command:
hadbm set TotalDatadeviceSizePerNode
This command restarts all the nodes, one by one, to apply the change. For more information on
using this command, see
“Conguring HADB” in Sun GlassFish Enterprise Server 2.1 High
Availability Administration Guide
.
Tuning HADB
Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide • January 2009108










