great news on the collections front. Currently our Rete is a synced
blocked so we know there wont be concurrent access to each collection
object, although ofcourse we do allow multiple working memories which
might both be evaluating in different threads - so probably need a db
per working memory. With regards to JTA we haven't given it too much
thought yet, just doing exploration at this stage, but its more to do
with exposing the transaction rollback back to the use in a standard api
- but we still have a lot to do here before we define this one more
thoroughly, will keep you informed when we have something more definite.
Alex Boisvert wrote:
> Hi Mark,
> Supporting the Collections API is on our TODO list; there are a few
> patches floating around that may help you get started. We'll work on
> integrating those to the base distribution shortly.
> As for JTA support, this is a more complex subject. JDBM isn't a real
> OLTP provider; it doesn't natively support multiple concurrent
> transactions. We do have basic commit/rollback semantics but we don't
> have any of the more refined transaction support that you would
> normally find in a complex database system such as
> optimistic/pessimistic locking, MVCC, etc.
> Also, why you need JTA support in a rules engine is beyond me... Can
> you provide some more context?
> Mark Proctor wrote:
>> The Drools, http://drools.org/, Rete implementation is a collection
>> of maps, sets and lists in a directed graph. We are looking to
>> optionally make those collections transactional and/or persisteable.
>> Sleepycat Berkeley DB Java edition looked perfect for this, but the
>> license is innappropriate for Drools :( so Brian McCallister pointed
>> me in your direction. After looking at you api seems you peeps are
>> heading in the right direction, so I thought I would put my requests
>> in features :)
>> 1) Map, Set and List implementations, even if partially implemented
>> and throw NotImplemented runtime exceptions.
>> 2) JTA implementation for transactions. Have you seen commons
>> transactions? http://jakarta.apache.org/commons/transaction/ makes
>> any Map transactional.
>> The idea is for normal use we use standard collection
>> implementations, for those that wish it we can add transaction
>> support and further still persistence support.
>> Not sure if this is of any use, but thought I would mention it anyway
>> as I have to eventually make this transactional and persisteable and
>> maybe I would be better of making those changes to jdbm. I wrote an
>> ultra light weight and stunted Map like implementation for our object
>> cache lookup in Drools. I blogged it when I first wrote it, with
>> benchmarks against other similar implementations. Its only useful for
>> int/long lookups, but feel free to rip if you find it useful -
>> feedback welcome :)
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>> & QA
>> Security * Process Improvement & Measurement *
>> Jdbm-general mailing list