Jörn Nettingsmeier schrieb: > Andreas Hartmann wrote: >> Jörn Nettingsmeier schrieb: >> >>> Andreas Hartmann wrote: >> >>>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for >>>>> each source URI only one RCML object is created. This allows to >>>>> synchronize access to the RCML methods, avoiding concurrent >>>>> modifications. >>> let me see if i'm getting this: a source URI is a uuid? or a uuid >>> plus language? or uuid plus language plus revision? no, the last >>> wouldn't make sense... can you elaborate? >> >> ATM source URIs are lenya:// URIs. E.g., the sitetree has a source URI >> which doesn't contain a UUID. > > ah, so the revision controller still uses the old repository access > based on the sitetree path...
Actually it's not old - it's the normal way to access repository nodes. > so iiuc, in terms of the new repository > api, we have one SouceNodeRCML per uuid per language. which implies that > users can work on different translations of the same document > concurrently. nice. Yes, but this was already possible before the change. >>> what happens to other sessions that want to commit? do they spin, >>> or are they being notified, or does the user see an error and is >>> prompted to retry? >> >> They are just blocked by the JVM. > > ah, nice. in unix terms, that would mean they are not spinning (polling > regularly), but go to sleep and are only re-activated when the resource > is available again... so it's easy on server resources. Yes, I guess so - but actually I have no idea what the JVM exactly does. But since synchronization is a quite common concept in Java, I guess there is some kind of optimization :) > >> Committing a session should usually >> be a matter of some milliseconds, so the user shouln't notice. It >> can happen in high load conditions, though. > > well, as long as the user is not forced to do something special to fix > it, it's fine. waiting a second is ok imho (for now - eventually we'll > have to tune lenya for speed, but certainly not now :) The synching happens only when a session is committed, which will probably occur very rarely in user-driven environments. >> I know this isn't the >> most elegant approach, but in this area we should go for the safest >> solution. Synchronization issues in the commit stage can lead to an >> inconsistent repository (which occured during my load tests). > > i like it. it's safe, non-intrusive and easy to verify, which is good. > from your first comment, i wasn't sure if you just were just making it > fail like the indexing, and the user would have to take some action... > > thanks for your comments, Thank you too for forcing me to clarify :) -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
