Hi
Thanks for your responses. I just wanted a temporary work around till the
actual feature is implemented, even at the cost of performance. I have
thought of another approach to this problem.
I plan to use my own transaction mechanism instead of Ignite transactions. I
can use explicit locks
Okay, thank you. Nice to know it is under development.
Best,
Rick
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
On Mon, Sep 18, 2017 at 8:01 AM, rick_tem wrote:
> I see that as a huge problem. Certainly one of the functions of Ignite is
> to
> be faster than the database, but if it fails to meet all of the
> requirements
> of what a database will do for you, what is the point of
As Vladimir mentioned, this is one of the features that is simply not
implemented yet. Transactional support for SQL is in development right now.
Hopefully we will have sometime this year, or probably early next year.
-Val
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
I see that as a huge problem. Certainly one of the functions of Ignite is to
be faster than the database, but if it fails to meet all of the requirements
of what a database will do for you, what is the point of using it? Clearly a
database will keep read consistency between transactions. Most
Hi,
Looks like you need the feature which is simply not implement in Ignite at
the moment. SELECTs are not transactional and there is not easy way to make
not-yet-committed updates visible to them. Solution 1 doesn't work as there
are not "temporal" caches in Ignite. Not-yet-committed updates are
Andrey,
This was just a wrong link. Nikolay already provided the correct one above:
https://issues.apache.org/jira/browse/IGNITE-3478
-Val
--
View this message in context:
This means that if you execute a query in the middle of commit, you can see
partial results. E.g., there is a transaction which updates 10 entries, it
already committed 5 of them and is about to commit other 5. A query at this
moment of time will already see committed entries.
-Val
--
View
JIRA wrote
> concurrent SQL query can see partially committed transaction
I thought the problem is SQL doesn't see uncommited changes at all (even
from my thread). But this means SQL can see some part of uncommited
transaction? How it is possible?
--
View this message in context:
Yes in theory I could know all changes I made. But in practice it will make
application logic so much more complicated!
E.g in one part of transaction I create an object and in some other part
execute query which should include this object in result cursor taking into
account WHERE and ORDER BY.
If you're executing a query from the same transaction where you updated the
data, I'm pretty sure you can find a workaround, because you know everything
about the updates made within the transaction. Transactional SQL feature is
mostly designed to avoid dirty reads in case a query transaction and
It depends on when someone from the community takes over this task getting it
done. If to refer to previous discussion we should expect the feature appear in
Ignite in the beginning of the next year.
—
Denis
> On Sep 13, 2016, at 3:15 AM, akaptsan wrote:
>
> I would say
I would say it's critical problem. Can you estimate when it will be fixed?
(I don't have access to jira)
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Query-does-not-include-objects-added-into-Cache-from-within-a-transaction-tp7651p7703.html
Sent from the
Hi,
I am using ignite cache in transactional mode. When I do a query on the
cache from within the transaction, the query results do not include the
objects put into the cache from within the transaction, even though the
query is fired from within the same transaction. The objects appear in the
14 matches
Mail list logo