Jukka Zitting wrote:
Would you design a relational database client that leaves a
transaction open like that for extended amounts of time? I don't think
that's best practice.
It is not - for majority use-cases but in limited resource environment it is.
And yes it is cheaper to re-use and keep open session rather than produce
garbage. Jukka have you tried to write something when you have 64k heap ?
And to minimize application footprint I will consider keep session alive for
standalone and embedded applications, if it make sense.
In fact I think JCR is better suited for managing such long-lived
draft content for the very reason that the transient changes are
clearly separate from the persistent storage and can be handled
entirely on the client side of a client-server model. A relational
database typically (at least) write-locks all rows that are being
modified in a transaction.
It depends on your isolation level, and often they are not locked, that will
bring concurrent modification issues, but it is a different topic :) I will
stick to our issues.
--
Ivan Latysh
[EMAIL PROTECTED]
