- 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]
"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?
Chec
Yes, 3 is a good way if transactionsa are very "short" (transaction per
operation aka autocommit),
it solves deadlock problem and most of conflicts ( optimistic loclking can
solve the rest ).
But I do not think all of applications can use this way, most of my
applications can't.
Think about Gavin'
"Juozas Baliuka" <[EMAIL PROTECTED]> writes:
> Databases lock updated and deleted rows only and transaction blocks
> on conflict only, it never block query or not conflictiong updates,
> I see three ways to solve update conflict:
> 1) block transaction
> 2) abort transaction
> 3) no concurent tra
- Original Message -
From: "Adam Megacz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 27, 2003 4:46 AM
Subject: [Hibernate] in-memory databases vs query-in-memory databases
>
> Okay, this isn't 100% hibernate-related, but I fi
Gavin King <[EMAIL PROTECTED]> writes:
> What of you need to make a remote call, or send a message inside the
> txn? Your analysis assumes that the system is not distributed in any way. :)
Optimistic locking can be layered on top of a system like this.
I don't believe that non-optimistically-lo
What of you need to make a remote call, or send a message inside the
txn? Your analysis assumes that the system is not distributed in any way. :)
Adam Megacz wrote:
Okay, this isn't 100% hibernate-related, but I figure you guys think a
lot about stuff like this.
Prevayler's pitch goes something
Okay, this isn't 100% hibernate-related, but I figure you guys think a
lot about stuff like this.
Prevayler's pitch goes something like this: "if all your data fits in
memory, you don't need concurrent transactions, because every
transaction will be demanding the same resource (cpu/memory
bandwid
