Re: Future of Prevayler?

Ross Rick <[email protected]>
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
I would like to comment on comments here if you don't mind. 

R


On Apr 16, 2010, at 1:56 PM, Klaus Wuestefeld wrote:

>>        A built in serialization with AVRO   (http://hadoop.apache.org/avro/)
> 
> Interesting.

[RGR] To me it's very interesting because it should read and write much faster than java serialization and schema management would be a lot easier.  Others would probably find multiple uses in web server scenario with only a little work deserializing small parts into javascript for client use.


> 
> 
>>       Journal and Snapshot cleanup/management
> 
> I agree.
> 
> 
>>        A mechanism for arbitrary transactions ( startTx(), endTx() )
> 
> Questionable benefits and doable only with heavy code instrumentation.
> 

It would be a bummer if it was hard to do.   We had built a similar mechanism over HSQL.  I'm using the royal 'we', smarter people than I did the work.  It was done by making the transactional context re-entrant, and reference counting all the way.    So if you started a transaction and called methods that normally transacted themselves the transaction mechanism would just bump the count.  On the way out, only the very last end transaction actually commits.  So more like nested transactions, but really handy.   Lets say you had an data bean like a User with fields like name, age, userid, userType, email, etc.  The truth is that most actions transact single changes.   So you could write your  set methods to automatically transact.  No one ever has to worry about safety. But when the user is
  filling out a form, or changing thousands of users in one go, the client would simply open the transaction, loop through the users and change them.  Commit at the end.    

Then I, as the data model / API provider don't have to write a transaction explicitly for every type of change users want to do.


> 
>>        A long term strategy for passivation of object graph sections
> 
> Also requires heavy instrumentation and opens the OODBMS can of worms.
> 
> I dont know if a switchable Prevayler<->OODBMS system makes sense. It might.
> 
> See you, Klaus.
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
> 


------------------------------------------------------------------------------
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.