I guess my question here is what the benefit to sharing a schema is?  You
can already have multiple brokers running against the same Oracle
installation as long as they are using different schemas... If they use the
same schema would we be expecting the instances to store their data in the
same tables?  If so what would happen when a new version of Qpid comes out
that updates the table structures?  At the moment the upgrade process
converts all the data in the tables into any new table structure, but how
would that wrk if there were data from multiple Qpid installations in
there?  Sharing tables would also seem to potentially cause more contention
between instances that would not occur if the data for different instance
is held separately,

-- Rob

On 30 November 2016 at 08:32, Keith W <keith.w...@gmail.com> wrote:

> Hi Rawad
>
> Your analysis of the code is correct, currently the JDBCMessageStore
> feature assumes exclusive use of the a schema.    This is really a
> reflection of the way this store module evolved - out of the Derby
> store.  It probably would not be too hard to change the code so that
> sharing a schema becomes possible, but it is not something on the road
> map for the near future.  If the feature would be useful to you, feel
> free to submit a patch.
>
> Kind regards, Keith Wall.
>
>
>
> On 29 November 2016 at 16:19, Rawad Assaf <rawad.as...@gmail.com> wrote:
> > Hi,
> >
> > I am trying to use a JDBC message store to persist messages of the
> default
> > virtualhost on an Oracle RDBMS.
> >
> > Looking at the SQL statements used (as per
> > https://github.com/apache/qpid-java/blob/trunk/broker-
> core/src/main/java/org/apache/qpid/server/store/
> AbstractJDBCMessageStore.java)
> > it doesn't look as if I can persist messages from multiple brokers in the
> > same Database Instance.
> >
> > Is this really the case? If yes, are there any plans to add such a
> feature
> > in future? It would be really practical not to have to create a separate
> > Database Instance for each broker.
> >
> >
> > Best regards,
> > Rawad.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to