> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, June 26, 2001 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] High load...
>
>
> |Sorry Georg, I don't what planet I was on when I made the "option A with
> |optimistic locking" comment.
>
> Option A with optimistic locking would be interesting.
>
> it is Option A with pessimistic db locking that doesn't really bring
> anything new.
>
> He was criticizing the "no copy of the cache" for a new transaction. I
> answered with the clone idea in teh cache.
>
Yeah, I saw your reply to Georg about the deep copying the cache. Good
idea...
> The point is that these are CACHE IMPLEMENTATION dependent, I
> will make sure
> the container flow supports these.
>
> |Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate
> |SQL*PLUS windows. With autocommit off, it seems that if you try
> to update
> |the same row in 2 different windows, one window waits until the other
> |commits. Wonder if this will happen with JDBC as well, I'll let you
>
> pessimistic then...
>
> |know....Anybody know the behaviour on this with other DBs? Is
> this common
> |locking behaviour? If so, great!
>
> we would have to implement the transaction isolation levels correctly in
> jboss again I believe that lives at the jbossCMP level. But if
> we are going
> to support different vendors for the CMP engines we must take
> this part out
> or at least offer a common API... hmmm must think about it.
>
Isolation levels and locking are really orthonogal, aren't they?
> |All in all, I think JBOSS should delegate synching and locking to the DB
>
> sure but my point is that can be a cache decision, if you still want to
> implement a pessimistic cache (like we have right now) with maybe a simple
> "read-only" feature then you can.
>
I still think you should enable the ability to push the pessimistic locking
onto the DB with CMP, or onto the developer for BMP. In our app, for
instance, we have common, rarely-updated, entities that are shared alot
between transactions. Since the current JBoss code-base locks entities into
a transaction we are forced to use straight JDBC to avoid the unnecessary
locks. I'd really like to avoid mixing JDBC with EJB wherever possible. I
guess this should be put off for 3.0 though...
> In fact a READ ONLY cache could really improve throughput with
> copies of the
> instances for the duration of the transaction. It is then the cache
> workspace that becomes XA aware... hmmm must think about it.
>
> Add-on market??? here we come... we must enable these policies,
> that is what
> I am fixing.
>
Can't wait to use this stuff....
> |wherever it can because the DB is usually more efficient at this. Also,
> |IMHO, this is really the best way to synch multiple instances of JBoss.
>
> hmmmmm maybe... maybe not... some will argue that letting all the
> cache sync
> on the database is not the best option... it is definitely the *simplest*
> but certainly not the "best".. :)
>
(This should really be in a separate thread, but...) I really can't see the
advantages of synching multiple instances of JBoss without using the DB.
Otherwise you'd have to have a lot of expensive network communication
between these instances and probably some pretty complex logic as well. The
DB is made for this sort of thing, isn't it? Actually, don't bother
replying to this, because I really lack the experience to comment on
this....
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
