imho, i think that using aop is going to have a bigger impact then reading the database. because you are going to read the process variables during the client request. the process variables might not be loaded from the database, so accessing them will load them from the db.
why not join forces ? i believe that your efforts can be a very valuable contribution to jbpm. i don't think that developing a generic bam solution that plugs into every workflow engine is realistic. workflow and BPM engines do not (yet) have a common foundation. differences are too big so you can't provide much usefull functionalities on that.
from the few images i could find on your website, it seems that you know what you are talking about. i am interested to invest my time in evaluating, stimulating your ideas and giving you cvs access once we find some degree of concensus.
i sinserely believe that trying to build a generic bam engine will get stuck in technical issues bridging the gap between all the engines. joining forces will get your work distributed approx 10000 times per month and you can develop much more usefull features.
it could beginning of very interesting and valuable cooperation. i think we should arrange a voice meeting between our team and you. right now we are writing the design documents and soon they will be posted on our project site.
please contact me via email, so we could arrange our meeting.
Interesting. I'm looking forward to seeing great things coming out of this cooperation.
Regarding the original issue, variables are loaded on demand from the database, as Tom explains. Our implementation of the receive activity depends on persistence. There is no way to run completely in memory unless you don't receive at all.