Database Management Systems

Hibernate Session objects are NOT thread-safe. Each thread should have its own Session instance, or you need to implement proper synchronization. Sharing a Session across threads can lead to race conditions, data corruption, and unpredictable behavior. This is a fundamental design choice in Hibernate.

Hibernate Sessions use lazy connection acquisition - they only obtain a JDBC Connection or DataSource when actually needed for database operations. This reduces unnecessary database connections and improves resource utilization. The connection isn't created on Session instantiation or object creation.

Query cache in Hibernate is enabled by setting hibernate.cache.use_query_cache to true. This caches the actual query results along with identifiers. Note that you must also enable second-level cache and mark specific queries as cacheable using setCacheable(true).

XML is a variable-length data type in DB2 that stores hierarchical data without a fixed size. INT, CHAR, and DOUBLE all have fixed storage lengths (4 bytes, defined length, and 8 bytes respectively).

Bufferpools are memory cache areas used by DB2 for data buffering, not database objects that can be locked. Locks can be applied to table spaces, tables, and rows to control concurrent access.

The Repeatable Read (RR) isolation level prevents phantom reads, ensuring that a query executed multiple times in the same transaction does not see new rows inserted by other applications. Read Stability (RS) only prevents modifications to existing rows but allows new rows to appear, making it incorrect here.

Routines (stored procedures and functions) contain executable code that can be invoked using SQL statements like CALL or in expressions. Views and tables are data structures only. Packages are containers for routines but aren't directly executed.

CO-PA and FI-SL DataSources in SAP BW are dynamically generated based on operating concerns and special ledgers, preventing direct enhancements in the source system using standard tools. In contrast, LO, FI-GL, and generic DataSources are designed to be easily enhanced with append structures in the source system.

Hibernate Session objects are NOT thread-safe. Each thread should use its own Session instance. Sharing a Session across threads can cause race conditions and data corruption.

Hibernate uses lazy connection acquisition - a Session only obtains a JDBC Connection when actually needed (e.g., executing a query). It doesn't fetch connections on Session creation or maintain a constant connection.

The correct property name is hibernate.cache.use_query_cache with value 'true'. This enables caching of query result sets. Option A has the wrong property name, and option C uses 'yes' instead of 'true'.

When hibernate.cache.use_query_cache is set to true, Hibernate enables two cache regions: StandardQueryCache (stores query results) and UpdateTimestampsCache (tracks table modification timestamps). UpdateTimestampsCache is crucial for validating cached query results. Options B and C miss the UpdateTimestampsCache region.

session.load() throws an unrecoverable ObjectNotFoundException if no matching database row exists, because load() expects the row to exist (it may return a proxy). This differs from session.get(), which returns null if no row is found. Options A and B are incorrect because load() does not return null or empty objects - it throws an exception.

CacheMode is configured on a per-Session basis to determine how that specific session interacts with the second-level cache (e.g. bypass, refresh, or read-only). The SessionFactory manages global configurations rather than individual session cache behaviors.

Query.list() retrieves all matching records in a single SQL SELECT query. Query.iterate() initially fetches only the database identifiers, requiring subsequent individual database queries for each entity not cached, resulting in poor N+1 query performance.