Return-Path: X-Original-To: apmail-ignite-user-archive@minotaur.apache.org Delivered-To: apmail-ignite-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D235018B0F for ; Sat, 9 Jan 2016 08:41:22 +0000 (UTC) Received: (qmail 54786 invoked by uid 500); 9 Jan 2016 08:41:22 -0000 Delivered-To: apmail-ignite-user-archive@ignite.apache.org Received: (qmail 54734 invoked by uid 500); 9 Jan 2016 08:41:22 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 54724 invoked by uid 99); 9 Jan 2016 08:41:22 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Jan 2016 08:41:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 342F5C0CFE for ; Sat, 9 Jan 2016 08:41:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.973 X-Spam-Level: *** X-Spam-Status: No, score=3.973 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id KEgvZ48HseeQ for ; Sat, 9 Jan 2016 08:41:12 +0000 (UTC) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id 4D288429D3 for ; Sat, 9 Jan 2016 08:41:12 +0000 (UTC) Received: from malf.nabble.com (unknown [162.253.133.59]) by mbob.nabble.com (Postfix) with ESMTP id 1EF291DC81DE for ; Sat, 9 Jan 2016 00:38:47 -0800 (PST) Date: Sat, 9 Jan 2016 00:30:34 -0800 (PST) From: akaptsan To: user@ignite.apache.org Message-ID: <01df01d14ab9$71a021a0$54e064e0$@mail.ru> In-Reply-To: <1452313562529-2453.post@n6.nabble.com> References: <1452161388409-2415.post@n6.nabble.com> <1452171644809-2430.post@n6.nabble.com> <1452227275018-2442.post@n6.nabble.com> <1452255961597-2449.post@n6.nabble.com> <1452256134253-2450.post@n6.nabble.com> <1452313562529-2453.post@n6.nabble.com> Subject: RE: Is there limitation on Semaphores and Queues? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_91042_1400172960.1452328234579" ------=_Part_91042_1400172960.1452328234579 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Denis =20 Thank you so much for helping me! But none of your suggestions really work for me L. =20 I can=E2=80=99t now switch my application to Ignate as primary storage. But= I do have this idea in remote plans. =20 I can=E2=80=99t use native RDBMS replication, because databases are not 100= % identical (in fact probably less then 50% of DB objects are identical).= =20 I do need application-level capturing and applying of changes.=20 =20 And main reason why I can=E2=80=99t use Kafka or similar messaging system i= s: I need to eliminate simultaneous change of one object in the two DBs. If= it happened, then the object state in DBs would be inconsistent. That=E2=80=99s why I want to use Ignite semaphore =20 =20 =20 From: Denis Magda [via Apache Ignite Users] [mailto:ml-node+s70518n2453h58@= n6.nabble.com]=20 Sent: Saturday, January 09, 2016 9:26 AM To: akaptsan Subject: Re: Is there limitation on Semaphores and Queues? =20 Anatoly,=20 Please properly subscribe to the user list (this way we will not have to=20 manually approve your emails and you will get answers on your questions qui= cker). All you need to do is send an email to =E2=80=9C=20 user-subscribe@ignite.apache.org=E2=80=9D and follow simple instructions in= the=20 reply=20 Since the content in the databases is almost identical and you have a load = balancer that directs queries to one of the systems I would review current = architecture design and probably switch to the following one. You can still= have a single Ignite in-memory cluster that will persist data [1] in one o= r several databases depending on your requirements and configuration. In su= ch a design all business model related queries will go directly to the clus= ter and you don't need to care about replication cause everything will be a= lready there. Ignite supports ANSI-99 SQL so your SQL queries should work f= ine as well[2].=20 If your systems are web applications then you may want to use web session c= lustering in addition [3].=20 On the other hand, if you can't switch to such an architecture then basing = on your description you are trying to implement a replication between the d= atabases and probably solutions like Kafka Connect [4] should work perfectl= y fine for you. Also different RDBMS vendors provide native tools for repli= cation between their databases. As an example replication between Oracle da= tabases can be done using Oracle Golden Gate product. I don't get why you n= eed to lock an Ignite object when you're applying changes, stored in queues= , from one database to another that's why consider that Kafka or RDBMS nati= ve replication tool will be enough.=20 Does any of suggestions work for you?=20 [1] https://apacheignite.readme.io/docs/persistent-store [2] https://apacheignite.readme.io/docs/sql-queries [3] https://apacheignite.readme.io/docs/web-session-clustering [4] http://kafka.apache.org/documentation.html=20 _____ =20 If you reply to this email, your message will be added to the discussion be= low: http://apache-ignite-users.70518.x6.nabble.com/Is-there-limitation-on-Semap= hores-and-Queues-tp2415p2453.html=20 To unsubscribe from Is there limitation on Semaphores and Queues?, click he= re . NAML=20 -- View this message in context: http://apache-ignite-users.70518.x6.nabble.co= m/Is-there-limitation-on-Semaphores-and-Queues-tp2415p2454.html Sent from the Apache Ignite Users mailing list archive at Nabble.com. ------=_Part_91042_1400172960.1452328234579 Content-Type: text/html; charset=UTF8 Content-Transfer-Encoding: quoted-printable

Denis

&n= bsp;

Thank you so much for help= ing me!

But none of your s= uggestions really work for me L.

 

I can=E2=80=99t now switch my application to Ignate as primary storage. = But I do have this idea in remote plans.

 

I ca= n=E2=80=99t use native RDBMS replication, because databases are not 100% id= entical (in fact probably less then 50% of DB objects are identical). =

I do need application-level ca= pturing and applying of changes.

 

And main re= ason why I can=E2=80=99t use Kafka or similar messaging system is: I need t= o eliminate simultaneous change of one object in the two DBs. If it happene= d, then the object state in DBs would be inconsistent.

That=E2=80=99s why I want to use Ignite semaph= ore

=C2=A0=C2=A0=C2=A0

 

=

 

Fro= m: Denis Magda [via Apache Ignite Users] [mailto:[hidden email]]
Sent: Saturday, January 09, 2= 016 9:26 AM
To: akaptsan
Subject: Re: Is there limitati= on on Semaphores and Queues?

 

Anatol= y,

Please properly subscribe to the user list (this way we will not= have to
manually approve your emails and you will get answers on your = questions quicker). All you need to do is send an email to =E2=80=9C
[hidden email]=E2=80=9D and follow = simple instructions in the
reply

Since the content in the datab= ases is almost identical and you have a load balancer that directs queries = to one of the systems I would review current architecture design and probab= ly switch to the following one. You can still have a single Ignite in-memor= y cluster that will persist data [1] in one or several databases depending = on your requirements and configuration. In such a design all business model= related queries will go directly to the cluster and you don't need to care= about replication cause everything will be already there. Ignite supports = ANSI-99 SQL so your SQL queries should work fine as well[2].

If you= r systems are web applications then you may want to use web session cluster= ing in addition [3].

On the other hand, if you can't switch to such= an architecture then basing on your description you are trying to implemen= t a replication between the databases and probably solutions like Kafka Con= nect [4] should work perfectly fine for you. Also different RDBMS vendors p= rovide native tools for replication between their databases. As an example = replication between Oracle databases can be done using Oracle Golden Gate p= roduct. I don't get why you need to lock an Ignite object when you're apply= ing changes, stored in queues, from one database to another that's why cons= ider that Kafka or RDBMS native replication tool will be enough.

Do= es any of suggestions work for you?

[1] https://apacheignite.readme.io/docs/persistent-store
[= 2] https://apacheignite.readme.io/docs/= sql-queries
[3] https= ://apacheignite.readme.io/docs/web-session-clustering
[4] http://kafka.apache.org/documentation.html

<= hr size=3D1 width=3D"100%" noshade style=3D'color:#CCCCCC' align=3Dcenter><= /div>

If you reply to this email, you= r message will be added to the discussion below:

<= /div>

http://apache-ignite-u= sers.70518.x6.nabble.com/Is-there-limitation-on-Semaphores-and-Queues-tp241= 5p2453.html

To unsubscribe from= Is there limitation on Semaphores and Queues?, click here.
NAML

=09 =09 =09
View this message in context: RE: Is there limitation on Semaphores and Queues?
Sent from the A= pache Ignite Users mailing list archive at Nabble.com.
------=_Part_91042_1400172960.1452328234579--