Sumedha,
sure, I understand: I also developed products that had to support multiple
RDBMS. But we ended up developing RDBMS specific code for performance
reasons. This of course depends on customer requirements, i.e. as long as
there are no customer complains, you are doing the right things :-)
Frank,
To make testing and development simple, we try to avoid database specific
code as much as possible with in Carbon platform. Currently most of the
products support close to 9 RDBMS engines.
99% of the SQLs we have in our DAO classes are ANSI compatible. However
there are database specific D
This is true in general: even a simple statement like SELECT behaves a bit
differently in different RDBMS implementations. I.e. minor differences in
SQL statements is not restricted to triggers, however we use RDBMS...
Best regards,
Frank
2014-09-12 10:24 GMT+02:00 Sumedha Rubasinghe :
> If yo
Prabath,
I agree that triggers make comprehending code a bit more difficult. But
triggers are a mechanism to achieve active database features, something
that is very difficult to get without triggers. Thus, I would not say that
they should not be used. I don't understand the statement that trigger
Hi Hasitha,
With this we can not get a clear idea on how data is going to store. It
would be better if you can give the flow of a message on these and how
subscriptions stored.
Note: Please send these mails the architecture.
Thanks
Shammi
On Fri, Sep 12, 2014 at 1:13 PM, Asitha Nanayakkara wro
In addition, triggers, usually, are like stored procedures in its context
and at times, might store some good portion of your business logic within
the database layer which makes them less visible to someone who's
evaluating a particular high-level business use-case just by looking at
some code lev
If you use triggers, you cannot have a database engine independent design.
On Fri, Sep 12, 2014 at 1:21 PM, Asitha Nanayakkara wrote:
> According to an offline chat I had with PrabathA SQL triggers should be
> avoided since SQL triggers execute outside SQL transactions.
>
> On Thu, Jul 24, 2014
According to an offline chat I had with PrabathA SQL triggers should be
avoided since SQL triggers execute outside SQL transactions.
On Thu, Jul 24, 2014 at 6:30 PM, Hasitha Hiranya wrote:
> Hi,
>
> According to mail arch@ "Removing Global Queue from MB", maybe we need to
> update this design.
>
Hi,
Following is the RDBMS design for WSO2 MB 3.0.0. Andes context store.
*Design Considerations*
- MessageStore and AndesContextStore can be two different types of
storage servers. Hence isolated from MessageStore related Database tables.
- In current Implementation *bindings* table
Hi,
According to mail arch@ "Removing Global Queue from MB", maybe we need to
update this design.
Better we discuss upfront if so.
It will bring changes to messageStore interface.
Thanks
On Thu, Jul 24, 2014 at 3:04 PM, Asitha Nanayakkara wrote:
> With the addition of message expiration feat
With the addition of message expiration feature RDBMS design for Metadata
in MB needs to be changed.
Updated design is as follows.
* Design considerations*
- Only a subset of messages comes with message expiration and a separate
thread handles deletion of expired messages.
- Periodic
With current design in memory message store will be used only in single
node mode.
On Wed, Jul 23, 2014 at 11:36 AM, Dhanuka Ranasinghe
wrote:
> Also, normally publisher mention whether to persist or not messages in
> message itself (delivery mode). So based on that MB will process messages
> i
Also, normally publisher mention whether to persist or not messages in
message itself (delivery mode). So based on that MB will process messages
in memory and/or persist to a persistence store. So if it's process in
memory How do we communicate through the MB cluster?
http://activemq.apache.org/wh
IMO, If we gonna keep huge messages as chunks in memory and insert into DB
as bulk it will heavily affect on MB heap memory. My suggestion is we need
to handle this case by case. For example, if it's small messages it will be
efficient to keep in memory while huge messages it will be efficient to
i
We are planning to insert message chunks as batch insert queries.
On Sat, Jul 19, 2014 at 11:00 AM, Dhanuka Ranasinghe
wrote:
> Are we going to insert whole message or as chunks
> On 18 Jul 2014 18:06, "Asitha Nanayakkara" wrote:
>
>> Hi,
>>
>> Following is the RDBMS design for WSO2 MB 3.0.0
Are we going to insert whole message or as chunks
On 18 Jul 2014 18:06, "Asitha Nanayakkara" wrote:
> Hi,
>
> Following is the RDBMS design for WSO2 MB 3.0.0
>
> Messages model
>
> Message metadata model
>
>
>
> Following are the concerns came across in the discussion
>
> *- Why we use referen
Hi,
Following is the RDBMS design for WSO2 MB 3.0.0
Messages model
Message metadata model
Following are the concerns came across in the discussion
*- Why we use reference counting for message meta data?*
Reference counting is needed to delete topic messages from the database
reliably in a
17 matches
Mail list logo
