----- Original Message -----
From: "Adam Megacz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 29, 2003 3:04 AM
Subject: Re: [Hibernate] in-memory databases vs query-in-memory databases


>
> "Juozas Baliuka" <[EMAIL PROTECTED]> writes:
> > Think about Gavin's example ( some of my applications use messaging
> > too) , most of my applications are integrated with "legacy" systems,
> > some of them use "import" it takes ~2 min.
>
> Why couldn't you use optimistic concurrency control for this?
> Checkpoint the system, do your import, and if the rows you needed
> changed during the 2-minute import, start over.

There is no locking in my use case ( no concurent write operations on this
table ), updated
rows are not visible before commit for read operations and import do not
block concurent read transactions.
It is always possible to find better ways, but it is easy to implement and
it works wo problems,
I will find a better way if it will stop to to work, bu I see no meaning to
solve not existing problems.

I am sure there are a good use cases for Prevayler.
BTW most of RDMS are designed the same way
1) redo/undo log files
2) tada and index files

As I understand Prevayler  uses redo log file and memory for data.
BTW you can try to use B+Tree indexed file with agresive cache for 2 and
performance will be almost the same on small databases and better  on large
databases ( index file is faster than swap )


>
> The "start over" part sounds awful, but the alternative (in a
> traditional multiple-outstanding-transaction ACID system) is to leave
> those rows locked for two minutes, which is (IMHO) equally awful.
>
> Perhaps I'm missing something here; I've dealt with a lot of
> highly-concurrent systems and implemented some hierarchical lock
> managers, but I've never dealt with attempted distributed transactions
> before.  Could you elaborate on the advantages of pessimistic locking
> in this situation?
>
> BTW, I don't really think Prevayler is a complete system, but I think
> they have hit upon a good layering that would greatly simplify a lot
> of systems.  They've only built the bottommost (very thin) layer; at a
> bare minimum you have to add optimistic locking, query parsing, and
> query optimization to get anything useful.
>
>   - a
>
> --
> "Education is not filling a bucket but lighting a fire." -- WB Yeats
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> hibernate-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Reply via email to