> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Monday, June 25, 2001 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] High load...
>
>
> |You should try this on some other OSes. I believe that the sun
> vm on linux
> |uses a one-to-one mode (one java thread to one native thread).
> This model
> |has problems with thread contension becase all thread contension
> |is resolved
> |in the kernel which has to pass through the native layer. Other
> OSes have
>
> I will try that on windows 2000, I will commit the code soon,
>
> |I think the important question is "Why do we have a passivation
> |cache?" Why
> |did we add it and is the circumstances that led us to add it still
> |valid. I
> |often find optimiztions in my client's code for situations that
> simply are
> |not a problem any more. Optimizations make code more difficult
> to read and
> |therefore maintian. (By the way, we could make a arument along
> |the lines of
> |scaleability vs. performance of a single instance)
> |
> |I am all for making the code as simple a possible,
>
> as I said the simpler design is with "nopassivation" stuff in it.
> I believe
> with gig ram machines floating around you can carefully design your
> deployment so that you will never need passivation.
>
> I will try to keep it in but seriously need to revisit that code,
>
> I will take a couple of days of rabbit hole (paid time) to try and
> streamline it, it is key to the scalability and speed of execution
>
> On the other hand it seems to be pretty robust, I can't say I
> have BROKEN it
> ;-)
>
A couple of points:
- Does your test MBean chuck random rollbacks into the stress test as well?
The original locking code seemed to be designed great if everything was
working well, but seemed to have less thought put into when error conditions
showed up(rollbacks).
- Also, do you really have to have "transactional" locks for entities when
you have commit option "B" and "C"? Wouldn't it be better to have an
instance per transaction and only do method locks?
- I plan on implementing a read-only instance interceptor for our app. We
never want to lock for any reason with read-only entities. Maybe this would
be useful in the code base.
- Somebody had a great idea earlier of adding "optimistic locking" for
CMP/JAWS. Along with this feature, you could write a specialized
EntityInstanceInterceptor that did not do "transactional locking" with
commit Option 'A'. This would be great for beans that had read-only invoked
operations 90% of the time.
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
