2008/1/22, rssh <[EMAIL PROTECTED]>: > > > > There is others ways to do what you want like calling setDatabase > > > > with a parameter "force" at database init for example only if > > > > "wiki.db" is set. > > > > > > > > > > Ok, I will look. > > > > > From reading source code: situation is more interesting, that I was think > before. > Why: > We need call setDatabase() not once per xwiki, but once per new > hibernate session. But sessions are controlled by hibernate, not by us. > Typical solution in such situation (near any middleware has something simular) > is to keep own weak map of sessions, and if database was not set for this > session -- set one. > > I see exists commented out 'ConcurrentHashMap' of connections (for > monitoring) which can server this purpose - but non-weak HashMap without > nurse process can cause memory leaks. (it's why one commented) > > So, my original plan now looks like incorrect, instead we must choose one from > three possible solutions: > > 1) [I guess best in short-term perspective] > Force setDatabase() in beginTransaction() only. > This will solve all security problems and partially - overhead. But we will > have non-empty overhead for non-virtual mode and non-empty xwiki.db, becouse > once-per-transaction is worse then once-per-session (but better than > onec-per-operation). Since this overhead will take place only when we set > xwiki.db, I think that this is acceptable and will submit appropriative patch. > (in case of absence of abjections). > > 2) Restore map of connections, but not as ConcurrentHashMap, but as > WeakHashMap with lock. This will restore functionality for monitoring, but > add overhead (I think small, but who know about large-scale installations) for > serializing sessions access. > > 3) In reality we need data structure, something like ConcurrentWeakHashMap. > [JBoss Remoting hase one]. We can get one from JBoss, but it's possible to > write one from scratch (and may be safer for license issues). > I think this is the best way in long-term perspective, but will require some > additional work. > > So, I want now do [1] and may be think about [3] in future, but without any > estimations of time.
I don't know hibernate enough at this time to be able to seriously comment your proposals [2] et [3]. About [1], as it not worst than virtual mode I think it could be acceptable if there is no other ways to do that. > > > > > > > Is the next strategy will be accessible (?) : > > > > > > 1. add to xwiki boolean member variable, which means, that 'database does > > > not > > > yet initialized'. > > > 2. enable setDatabase in non-virtyal mode only if we does not call yet > > > 'setDatabase' for this xwiki instance. > > > > > > This will fix security issue 'A' and partially - reduce extra overhead in > > > 'B'. > > > > > > So, is this plan looks normal ? > > > > > > > Yes, this sounds good to me. > > > > > > > > > > > > I don't say virtual/non-virtual separation can't be removed but it's > > > > another subject and imply more than just "allows to configurate name > > > > of database schema". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > patch is attached (tested with hsql in non-virtual mode in > > > > > > > addition > > > to oracle > > > > > > > in virtual/unvirtual). I will attach one to jira thought few > > > > > > > seconds. > > > > > > > > > > > > > > P.S. also note, that exitsts hibernate property 'default_schema' > > > which (when > > > > > > > we change name) must not conflict with xwiki.db > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > devs mailing list > > > > > > > > > [email protected] > > > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Thomas Mortagne > > > > > > > > _______________________________________________ > > > > > > > > devs mailing list > > > > > > > > [email protected] > > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ruslan Shevchenko > > > > > > > GradSoft. http://www.gradsoft.ua > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > devs mailing list > > > > > > > [email protected] > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thomas Mortagne > > > > > > _______________________________________________ > > > > > > devs mailing list > > > > > > [email protected] > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > -- > > > > > Ruslan Shevchenko > > > > > GradSoft. http://www.gradsoft.ua > > > > > > > > > > _______________________________________________ > > > > > devs mailing list > > > > > [email protected] > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > -- > > > > Thomas Mortagne > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > -- > > > Ruslan Shevchenko > > > GradSoft. http://www.gradsoft.ua > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > When you will have a nice implementation that works on all databases, > > this feature will need a vote I think as it touch a very important > > part of XWiki engine. > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Ruslan Shevchenko > GradSoft. http://www.gradsoft.ua > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
