I apologize in advance for introducing me in this thread...

> Dain,
> 
> full rundown is at http://www.castor.org/locking.html but my 
> brief version here...  (forgive me if any of this comes 
> across as patronizing, not sure how much exposure you've had 
> to castor)
> 
> say I had ejb and web tiers in the same jvm, and a jsp was 
> provided with a collection of objects to display.
> 
> in castor, I could have two requests at the same time, both 
> given the same collection of objects, and access them in a 
> read-only fashion concurrently.
> 
> (as I understand) with entity beans, using finder methods, as 
> soon as one entity was accessed, even in a read-only fashion, 
> it would be locked for the duration of that tx yes?  so the 
> second request would have to wait until the first tx has 
> finished.  the common workaround is to write the query 
> yourself in jdbc, and use a non-ejb approach....

Is this problem not solved using EntityMultiInstanceInterceptor ?
I mean commit-option "any" / EntityInstanceInterceptor seems to
serialize access to the Cache. Then I agree with you.
Have you try to swicth to commit-option B/C /
EntityMultiInstanceInterceptor ?
What I don't understand yet is that plus the Entity/Method Lock
interceptors plus the locking-policy that can be used along with that.
That mixed with the fact that finder methods create multiple instances
and I am in a black hole...

> 
> I know that read-only beans could solve this in some cases, 
> but obviously not all.  My real problem with the jdbc 
> approach is that hte container already has all the 
> information required to create the sql.
> 
> a while back, I tried to create some new functionality for 
> jboss, got it working nicely, but then faded away - 
> essentially, for each finder method, I made a query method - 
> basically following the architecture you have for the jaws 
> stuff - I mirrored FindEntitiesCOmmand with a 
> QueryEntitiesCommand (with a little refactoring to suit), and 
> in jboss.xml had a spot for someone to declare the class the 
> populate.  so the home interface then has:
> 
>   public Collection findByXXX();
>   public Collection queryByXXX();
> 
> the finder method of course returns ejbobjects, with all the 
> spec behaviour. the query method returns a collection of 
> dataobjects, the dataobject having the same set/get methods 
> as the entity bean, but is actually a copy of the data.
> 
> I had a fair bit of fun doing this, but got stumped on how to 
> handle relationships....  anyway, not sure that you couldn't 
> think of a much better way to solve the problem, but thought 
> it might be worth sharing, just seems that using jdbc for 
> read-only access was quite common, and could be another area 
> where jboss could make it easier for the user....
> 
> would like to hear your thoughts on this, and also any more 
> feedback on the castor issue.
> 
> cheesr
> dim
> 



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to