Session timeout interrupts batch validation jobs in validation management causing incomplete processing

PLM Oracle Agile PLM
, , , , , , , ,
1

Our batch validation jobs in validation-mgmt are failing midway through processing large datasets. We’re running Agile 9.3.4 and processing validation batches of 2000-3000 items overnight. The jobs start successfully but consistently fail after about 45-50 minutes with session timeout errors.

The validation process reliability is compromised because we can’t complete full batch runs. We’ve tried breaking batches into smaller chunks, but that creates incomplete validation coverage and makes it difficult to optimize the overall workflow.

Error log shows:


SessionTimeoutException: User session expired
at ValidationProcessor.processItem(line 342)
at BatchJobExecutor.run(line 156)

Session timeout is set to 60 minutes in the admin console, but jobs are timing out earlier than that. We need proper session timeout tuning for long-running batch operations without compromising security for interactive users. How do others handle extended batch validation jobs while maintaining appropriate session controls?

2

That’s a good point. Looking at our job configuration, the batch validation is initiated through the validation-mgmt UI by a user, and it appears to maintain that user’s session context throughout execution. We don’t have a dedicated system service account configured for batch operations. Is there a way to configure validation jobs to run as system processes after user initiation?

3

While solving the technical issue, consider the security implications. If you’re running batch jobs under a system account, ensure that account has appropriate audit logging enabled and restricted privileges. We’ve seen cases where overly permissive system accounts created security vulnerabilities. Document the service account’s purpose and access rights clearly for compliance reviews.

4

Let me provide a comprehensive solution addressing session timeout tuning, batch job optimization, and validation process reliability for your scenario.

Architecture Solution:

The core issue is mixing interactive user sessions with long-running batch operations. Here’s the proper implementation approach:

1. Session Timeout Tuning - Multi-Layer Configuration:

First, align all timeout settings across the stack:

# agile.properties
com.agile.session.timeout=3600000
com.agile.batch.session.enabled=false
com.agile.batch.system.context=true

Application server configuration (WebLogic):

<session-descriptor>
  <timeout-secs>3600</timeout-secs>
</session-descriptor>

However, extending timeouts for batch jobs is NOT the recommended solution.

2. Batch Job Optimization - Proper Implementation:

Refactor validation jobs to use the AgileScheduledJob framework:

public class ValidationBatchJob extends AgileScheduledJob {
    public void execute() {
        IAgileSession systemSession = getSystemSession();
        // Batch processing logic here
    }
}

Register the job in scheduled-jobs.xml:

<job name="ValidationBatch" class="ValidationBatchJob">
  <trigger type="manual"/>
</job>

3. Validation Process Reliability - Complete Solution:

Implement checkpointing for large batch operations:

// Pseudocode - Key implementation steps:
1. Initialize batch job with checkpoint manager
2. Process items in chunks of 500 records
3. After each chunk, persist progress state to database
4. If job fails, resume from last successful checkpoint
5. Update validation status table with completion metrics
// See Agile SDK documentation: Batch Processing Guide

Implementation Steps:

  1. Create System Service Account:

    • Create dedicated user “BATCH_VALIDATION_SVC” with minimal required privileges
    • Grant only validation-mgmt access and necessary read permissions
    • Enable audit logging for this account

  2. Deploy Scheduled Job:

    • Package ValidationBatchJob class in custom JAR
    • Deploy to `$AGILE_HOME/integration/sdk/extensions
    • Register in scheduled-jobs.xml configuration
    • Restart application server

  3. Configure Checkpointing:

    • Create checkpoint tracking table in Agile database
    • Implement progress persistence every 500 items
    • Add recovery logic to resume from last checkpoint

  4. Update UI Trigger:

    • Modify validation-mgmt interface to launch scheduled job instead of direct execution
    • Job runs asynchronously under system context
    • User receives job ID for status tracking

Performance Optimization:

  • Set batch chunk size to 500 items (balances memory and checkpoint frequency)
  • Enable parallel processing for independent validation rules
  • Configure connection pool: maxActive=50, maxIdle=20 for batch operations
  • Schedule jobs during off-peak hours to maximize available resources

Monitoring and Reliability:

Add comprehensive logging:

log4j.logger.com.agile.validation.batch=DEBUG, BATCH_LOG
log4j.additivity.com.agile.validation.batch=false

Implement job monitoring dashboard showing:

  • Current progress (items processed / total items)
  • Estimated completion time
  • Checkpoint status
  • Failure recovery status

Testing Validation:

  1. Test with 5000-item batch to verify no timeout issues
  2. Simulate mid-job failure and verify checkpoint recovery
  3. Monitor system session usage to confirm no user session dependency
  4. Validate audit trail captures all batch operations under service account

This solution eliminates session timeout constraints entirely for batch operations while maintaining security through proper service account implementation and comprehensive audit logging. Your validation jobs will now complete reliably regardless of duration, with automatic recovery capability if interruptions occur.

5

Batch jobs shouldn’t use user sessions at all. They should run under a system service account with different timeout rules. Check if your validation jobs are incorrectly inheriting user session context instead of running as background system processes.

6

Good catch on the app server timeout. I checked and WebLogic is indeed set to 30 minutes, which explains why jobs fail before reaching Agile’s 60-minute limit.

7

You need to implement the batch job as an asynchronous process that detaches from the initiating user session. In 9.3.4, use the AgileScheduledJob framework instead of running validation directly from user context. The scheduled job runs under the system context with no session timeout limitations. You can still trigger it manually from the UI, but execution happens independently. This also improves batch job optimization since the system can manage resources more efficiently for background processes.

8

Another consideration for session timeout tuning: check the application server timeout settings, not just Agile’s configuration. WebLogic or Tomcat might have their own session timeout that’s shorter than Agile’s setting. We had a similar issue where the app server was timing out sessions at 30 minutes regardless of Agile’s 60-minute configuration.