Hello-
For such a large system, it makes little sense to mirror data stored in a
database in a RBS knowledgebase as well. Rather, this problem seems
perfectly suited for a transaction based RDBMS. Many of the rules can
probably be placed in database functions and triggers.
You may still wish to use JESS as part of a higher level interaction/
management layer (often easier than managing lots of triggers), but the
actual data manipulation should probably be deferred to SQL UPDATEs.
I.e., don't create facts for individual rows of ResultSets. Keep the
ResultSet as a JDBC object, and write the rules to manage the data at this
level.
The proper use of commit/rollback transaction features in the database
server should ensure that the data integrity is maintained in the event of
power loss or other failures. Transactions that don't complete should be
automatically rolled back. JESS doesn't inherently possess transaction
support.
It also sounds like you may want to upgrade your server hardware to
account for the potential size of the job, including a RAID, UPS, multiple
CPUs, etc. JESS doesn't prevent multithreading, but proper
synchronization is still up to you. A good database server is naturally
multithreaded. You'll need to perform some real world benchmarks to size
things properly.
-Dave Barnett
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
