|Isolation levels and locking are really orthonogal, aren't they?
mmmm not entirely for example if we decide to NOT lock at the cache level
something that the new cache design will allow then you need to make sure
that isolation levels are such that you don't corrupt your db.
yes the code that locks at the cache level is independent but the data
consistency picture requires one or the other to function properly.
|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
the new caches will allow that with really configurable caches and locking
policies.
|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...
yes 3.0 (coding it right now) will allow you to specify "read-only" cache
policies, where a copy of the ctx will be enough (no need to copy the
instance)
|Can't wait to use this stuff....
no dummy I am saying *I* can't wait for you to write the cache (I will just
make sure the container works in all cases, today it doesn't the policy for
locking is hardcoded and pessimistic.).
The moment you do, feel free to add it to the code base of JBO or sell it
for awhile to finance your work and then switch to a real free license
(LGPL).
|> 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....
cache design is a bitch... my goal for 3.0 is to provide a DUMB DOWN
distributed cache (probably leveraging some JINI technology) will be slow
but will work... then we can graduate to "oswego" cache notifications.
Letting the db blindly update the distributed caches through heavy queries
is probably not the best use of network and resources. It is the simplest,
clearly not the best.
In fact now that you mention it, the easiest way to provide the clustering
is indeed with a kill of the db by letting it refresh the distributed caches
on ejbLoad forced by option B... brain dead but will work tada! clustering
v0.0.1 db-> jini->oswego->differential multicast
marcf
|Bill
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
