> > 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.
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
> > > > devs(a)xwiki.org
> > > >
http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > > --
> > > Thomas Mortagne
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > >
http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Ruslan Shevchenko
> > GradSoft.
http://www.gradsoft.ua
> >
> >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> >
http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft.
http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft.
http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft.
http://www.gradsoft.ua