If you are interested in increasing the priority of a particular feature, show your support by joining the mailing list, and requesting the feature to be increased in priority. If you would to spearhead development of a particular feature, join the development team today!
| Storable subclassing support |
A complex object data model requires
the ability of subclassing storable objects. Unfortunately the relational
model does not nativly support subclassing. Subclassed objects are stored
in the same table and are mapped directly onto their subclassed java objects,
allowing the full use of the java inheritence model. Query by subclass or
query by interface will also added to WhereQueries to limit the resulting
set of objects. |
Completed (v.0.91.4) |
Safe Servlet Restart |
When running a production site,
it is sometimes nessasary to update the site while users are in the system.
Assuming session objects (and the underlying data store) are compatable (or
is converted at startup), then it should be possible to confirm all existing
web requests are handled prior to restarting the servlet. This feature is
highly dependent on how your application server interprets the servlet spec.
The managertracker can even be configured to stay alive while a new servlet
is constructed, the old manager tracker would destroy itself when the final
remaining web requests were serviced. This should prevent any web connections
from being interrupted in a code upgrade. |
Completed (v.0.91.4) |
TransactionTracker Storable Cache |
When operating inside a transactional
context (such as with a TransactionTracker) storable object lookups should
be cached into a local memory store until the transaction is comitted or
finished. This will greatly increase lookup time for objects which have
already been restored from the database. Only a single instance of a given
storable object (Class x Primary Key) will exist. |
Completed (v.0.91.4) |
| Database Pool Abstraction Layer (Replication/Slave Load Balancing) |
This will allow load balancing over multiple MySQL databases servers to Storable. Multiple machines can be registered as Master or Slaves (in the case of MySQL, only 1 master). Read only load balancing will occur over the slaves registered in the slave pool, and write load balancing will occur over the masters registered in the master pool. Slave connections are configurable to compensate for "Replication delay" for applications which cannot allow an immediate write and immediate read of the same data to be returned from a slave who has not yet replicated the new data. Storable internally monitors (on TransactionTrackers only) the milliseconds since the last write of a particular Object, and if a read of the same Object is attempted in less then (Per Slave Configurable) milliseconds, the read request will go to the master and not a slave. | Completed (v0.91.1) Note: This change radically changes the manner in which database connections are defined in the configuration file. Note: There is no monitoring that the slave thread's replication is functioning properly, only that the database connections connect. Slave monitoring will be added with the Master Replication Protocol. |
| MySQL Multiple Master Replication (Master election protocol) |
An agent loaded on each MySQL database server monitors the servers for proper Replication, and announces itself as offline if the database server fails or replication is no longer functioning. Active polling will also locate failed servers which have gone completely dead. A Master election protocol will elect a new master in the case the current master fails. Remaining slaves which were not chosen for the new Master will be reconfigured to replicate off the new master, and all application servers using the database will have their slaves and master pools updated to reflect the new database Master and Slaves. Any MySQL active query running on an application server against a bunk server (either a failed Master or failed Slave) will be interrupted and restarted on a new operational server. When a failed master comes back online or a new slave is brought online, it will locate the current master, copy the tables down, and confirm it's replication is functioning before announcing itself as an active Slave. | Design complete. Awaiting implementation. (Requires JMS implementation) |
| Distributed Job Management | When an application outgrows a single application server, the current non-distributed job management design is no longer possible. Without a distributed job manager, a request coming into an application could not query the status of a job which was started on a different server. The distributed Job Manager allows querying running job objects prior to their completion (when they would be stored in the database). Jobs will no longer be executed as a thread inside a servlet context, but they will be handled by a separate Job processor. The distributed Job Manager will also support Job pools, so jobs are routed to the correct pool of servers to service the Job. This allows having dedicated servers for reporting, and also having separate servers handle certain classes of Jobs. This also will resolve the standing issue of Jobs running as a thread inside the servlet context when the servlet context is requested to destroy itself. | Completed (0.91.4)
(Requires JMS implementation) |
| Distributed Session Management | When an application outgrows a single application server the current non-distributed session management design is no longer effective unless you are able to distribute traffic over a set of application servers, while routing existing users back to the same application server reliably. Most persistent session implementations for use over a set of application servers (such as JServ) work in this fashion; the user must get sent back to the correct application server or their session is not available. Although most session implementations enforce this restriction, it only serves to reduce the net reliability of a particular application (just as RAID-0 reduces reliability). If an application server fails, all the sessions stored on that server are lost, and the users who were randomly assigned to that server have now have failed connections. This is acceptable for certain types applications, but quite unacceptable for others. The distributed session management system will store session keys, serialized, in to a database store. Defined interfaces for detecting changes will alleviate the burden of having to store the entire session back in the database after each request. This allows any particular application server to fail entirely, without affecting user session persistence. A content switch would simply route the request to another application server, who at a small start up expense, be able to restore the session from the database and continue processing the request. | Completed (0.91.4) Storable Backend Modifications Complete (v0.90.2) |
| PostgreSQL DBAdapter | Provide storable support for PostgreSQL relational databases | Requires BLOB implementation |
| Interbase DBAdapter | Provide storable support for Interbase relational databases | Requires BLOB implementation |
| Regression tests for Storable | Provide a set of tests which thoroughly exercise all storable functions. This would assist in the development of new DBAdapters and aid testing. | No design |
| Storable Profiling | Add a mode where storable profiles it's database queries to provide feedback to the programmer to optimization points. This would aid locating needed indexes, and locating slow and inefficient queries. | No design |
| Storable Selective Column loading | Allow the ability for selectively populating attributes of an object when instantiating objects from the database. This may expedite and reduce memory overload in certain cases when full object functionality is not required. | Complete (v0.90.1) |
| Storable Foreign key support | Provide a database independent mechanism to declare foreign key constraints. | No design |
| Storable Meta Object Protocol | Add the ability for a particular storable class to declare functions which will be called during certain parts of the storable execution. (Ex: During table instantiation, storable would call a particular function before and after. This would allow custom database specific commands to be issued at the proper time. Additional functions would be added for insert, update, instantiation.. etc) | Partial implementation in v0.91.4 |
| Template System Internationalization Support | Often distributing a web application in multiple languages is a business requirement. Babelfish may temporarily assist in this deliverable, but a true custom translation is required for a commercial product. Internationalization support in the template system will allow custom dictionaries to be build for languages and locales. Template files are kept in the engineers native language. Apollo automatically tracks incremental changes in native language templates, and generates incremental language change files for future translation cycles. These files can be then given to a translation company for an incremental translation of just the changed language in the templates since the last version. Once translation is done, it is merged back into the base, and the incremental files are reset, and start tracking new changes for the next translation cycle. | Design complete. Awaiting implementation. |
| EAM Localization Support | Often coupled with translating an application to a native language is the ability to process input of locale specific fields, such as currency, date, percentages, and decimals. The EAM would be able to recognize and properly parse these locale specific datatypes. This would also include a mechanism of outputting these locale specific datatypes into the template system. | Complete (v0.91.4) |
| Formal Documentation | Although the learn by example works may work for many cases, a more comprehensive documentation set is most likely needed. | Seeking Assistance. |
| Work Interface | The ability to easily parallelize
code can potentially increase application speed greatly. The work
interface creates an interface to multithreading "work" objects.
"Work" objects are light weight when compared to "Jobs". Work
"classes" are required; which define how and when worker threads are
instantiated for the worker pool.
To be interfaced with storable to allow non-blocking database requests through the use of proxy objects. This allows multiple parallel database requests, keeping the database server busy while application logic is executed. This is accomplished even while application logic is serially executed. To be interfaced with the Jini load distribution mechanism to locate "Work" threads on remote machines. |
Complete (v0.91.2)
|