Object stores are the foundational storage layer of the BoxLang cache engine. They provide the actual mechanism for storing, retrieving, and managing cached objects. While cache providers coordinate user interactions and act as a service layer, object stores handle the low-level data persistence and retrieval operations.
What are Object Stores?
An object store is a pluggable storage backend that implements the IObjectStore
interface. It determines how and where your cached data is stored - whether in memory, on disk, or in any custom storage mechanism you design.
Key Characteristics:
Storage Abstraction: Object stores abstract the underlying storage mechanism from the cache provider
Key Handling: They work with
Key
objects, allowing for case-sensitive or case-insensitive storage decisionsEntry Management: All data is stored as
ICacheEntry
objects for consistency across implementationsEviction Support: Integration with configurable eviction policies (LRU, MRU, LFU, etc.)
Lifecycle Management: Support for initialization, shutdown, and maintenance operations
Built-in Object Store Types
BoxLang provides several built-in object store implementations:
ConcurrentHashMap: Fast in-memory storage using Java's ConcurrentHashMap
ConcurrentSoftReference: Memory-conscious storage with soft references for automatic GC cleanup
Disk: Persistent disk-based storage for cache durability
Custom: Your own implementations
The IObjectStore Interface
To create a custom object store, you must implement the IObjectStore
interface in the Java language or in BoxLang by using implements="java:ortus.boxlang.runtime.cache.store.IObjectStore
Creating a Custom Object Store
Step 1: Extend AbstractStore (Recommended)
While you can implement IObjectStore
directly, extending AbstractStore
provides useful functionality like eviction policy management:
Step 2: Implement Core Storage Methods
The most critical methods to implement are the storage operations:
Step 3: Implement Introspection Methods
Provide methods for cache inspection and filtering:
Step 4: Implement Eviction Support
Integrate with the eviction policy system:
Step 5: Handle Bulk Operations
Implement bulk operations for better performance:
Configuration
You can register and use your custom object store via the caches configuration section by putting the full Java class path of the object store as the objectStore
key
Or you can use the createCache( name, provider, propertes )
method on the CacheService
and pass in a class or object instance for the objectStore
Best Practices
Performance Considerations
Thread Safety: Ensure your implementation is thread-safe as multiple threads will access it concurrently
Efficient Lookups: Optimize for fast key lookups as
get()
andlookup()
are called frequentlyBulk Operations: Implement bulk operations efficiently rather than iterating single operations
Memory Management: Consider memory usage patterns, especially for in-memory stores
Error Handling
Eviction Integration
Resource Management
Integration with Cache Providers
Your object store will be used by cache providers like BoxCacheProvider
. The provider handles:
Cache entry creation and metadata management
Event announcements (insert, update, remove)
Statistics tracking
Eviction scheduling
Configuration validation
Your object store focuses purely on storage operations, making the separation of concerns clean and maintainable.
Testing Your Custom Store
Create comprehensive tests for your custom object store:
Conclusion
Custom object stores provide powerful extensibility for the BoxLang cache engine. By implementing the IObjectStore
interface and following these patterns, you can create storage backends that meet your specific requirements, whether for performance, persistence, distribution, or integration with external systems.
The clean separation between cache providers and object stores ensures that your custom storage logic remains focused and testable while integrating seamlessly with the broader caching infrastructure.
Last updated
Was this helpful?