Thanx a lot for a precious indications!!! So I think I will set the implicit locking to false
thx again !! Le lun 13/01/2003 � 12:15, Mahler Thomas a �crit : > Hi again Kevin, > > <snip> > > > > > > It may sound strange but this is intended! Here is why: > > > The collection represented by the proxy might contain an object X. > > > If we do not load the proxy concurring transactions will > > never know that X > > > is (implicitely) > > > locked by the current transaction. > > > > > > > I agree with that but if the collection has not already been loaded is > > it necessary to lock the collections objects to the transaction. > > yes! Of course it would be possible to just place a pending lockrequest on > the collection-proxy (this is done by registering a listener to the proxy > for single object proxies already!). Using this pending lock one could delay > the locking until the proxy loads the collection. > But there is a difference between a *normal* instance proxy and a collection > proxy: > an instance proy represents exactly one instance. Thus all concurring > transactions will use the same proxy and on materializing the proxy the tx > with the pending lock request is called to perform the locking now. > > a collection proxy represents multiple objects. But as the proxy is mot > materialized the transaction does not know which instances belong to the > collection! > Thus a concurring transaction could try to lock an instance X. Of course X > could be part as the collection implicitely locked by tx1 but there is no > chance to detect this conflict without materializing the collection proxy. > > > > > > But there is a way out: > > > You can set ImplicitLocking=false in OJB.properties. This > > will disable > > > implicit (and recursive) locking. > > > Of course the user is responsible for proper explicit > > locking if implicit > > > locking is disabled! > > > > > > cheers, > > > Thomas > > > > Can't this be configured in the class-descriptor for each class ... or > > or for each reference > > sure this could be done. > > > humm ... using ODMG with no implicit locking ... what are the > > consequences of such a choice, do u think it's dangerous for > > the client > > app ? > > It's not dangerous. You just have to keep in mind that an instance must be > locked to avoid possible write collisions. > > cheers, > Thomas > > > > > > > > > > > > > Please answer this mail, because the lazy loading feature > > for me and > > > > loose it with ODMG is not very cool !!! > > > > -- > > > > too bad : ( > > > > > > Kevin Viet <[EMAIL PROTECTED]> > > > > ActiVia Networks > > > > > > > > > > > > > > > > > > > > Thx in advance > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > -- > > Kevin Viet <[EMAIL PROTECTED]> > > ActiVia Networks > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > ______________________________________________________________________ > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Kevin Viet <[EMAIL PROTECTED]> ActiVia Networks -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
