Zookeeper enables its users to verify their updates/deletions of znodes by providing the expected dataVersion of that znone.
My question is if there is a way to use the czxid (i.e. Creation event ID) alongside the dataVersion when verifying those actions.
I looked into the client and it seems that there is no way to do that, which frankly, is a bit of a surprise.
What I'm trying to say is that the dataVersion can possibly incorrectly match a provided version. I mean, if I'm dealing with a node that is constantly being created, updated, deleted, and so on, then the dataVersion field is reset whenever I delete that node and create it again.
Isn't it a better approach to be able to use the czxid and dataVersion when modifying znodes? And how can I achieve my goal given the the mentioned limitation?
Related
Is there anyway to check duplicate the message control id (MSH:10) in MSH segment using Mirth connect?
MSH|^~&|sss|xxx|INSTANCE2|KKLIU 0063/2021|20190905162034||ADT^A28^ADT_A05|Zx20190905162034|P|2.4|||NE|NE|||||
whenever message enters it needs to be validated whether duplicate of control id Zx20190905162034 is already processed or not?
Mirth will not do this for you, but you can write your own JavaScript transformer to check a database or your own set of previously encountered control ids.
Your JavaScript can make use of any appropriate Java classes.
The database check (you can implement this using code template) is the easier way out. You might want to designate the column storing MSH:10 values as a primary key or define an index on it. Queries against unique entries would be faster. Other alternatives include periodically redeploying the Channel while reading all MSH:10 values already in the database and placing them in a global map variable or maintained in an API that you can make a GET request to when processing every message. Any of the options depends on the number of records we are speaking about.
I incidentally created a wrong domain, or after some testing I wanted to delete the domain.
Should I do that? and How?
It's strongly recommended not to delete domain.
There could be some data like tasks associated with a domain in the Cadence system. There is no tooling to clean them yet. Simply delete the domain will lead to corruption. For example, there may be a timer task scheduled for 1 year later in that domain. If the domain is deleted, it may look okay right now. But one year later, when the timer fire, the system will be corrupted. By design Cadence needs to be strongly consistent. So the server cannot simply skip a timer task.
In most cases, you don't need to delete an existing domain. As long as you don't use it you are fine. Including cases like you created a domain with a wrong name, or you want to deprecate a domain. In those cases, just don't bother it.
Another case, you created a local domain but later on realized that it should be a global domain. It's recommended to just ignore the local domain.
There could some slightly better reasons to delete a domain. For example, in the above case, you want to keep using the same domain name for whatever reason.
!!Danger Zone!!
The ONLY case that you can delete a domain is the case that you are sure the domain has never been used at all.
The operation is as follow. Using your database tool:
For SQL:
DELETE FROM domains WHERE name ="<yourDomain>" LIMIT 1
For Cassandra:
SELECT domain FROM domains_by_name_v2 WHERE domains_partition=0 AND name ="<yourDomain>"
This will return the domainUUID.
Then delete the records from two table:
DELETE FROM domains_by_name_v2 WHERE domains_partition=1 AND name ="<yourDomain>" LIMIT 1;
DELETE FROM domains WHERE id = domainUUID LIMIT 1;
Is there any way with a persistent state store to allow for keys in a KeyValueStore to expire? I know there is a retention period in the persistentSessionStore, but it looks like that isn't KeyValue based.
There is no expiration mechanism atm. There is Jira feature request for this though: https://issues.apache.org/jira/browse/KAFKA-4212
What you can do it though, to register a punctuation and delete data manually. You would need to store the timestamp as part of the value though and scan the whole store to find old keys.
I have a requirement to create CQ pages programmatically. But the challenge is that the page name/uri should be autogenerated combination of a string + unique number (eg. PT2000, PT2001).
Can someone tell me a way way to generate an autoincrement-id/constant in CQ in a way that the id's are unique even with multiple concurrent request?
Use a service that provides you with the ID and that manages the counter inside a volatile instance variable to make sure that state changes by one thread are immediately communicated to all other threads.
This should do the trick as long as your can guarantee that your implementation runs on a single author node. In a cluster scenario you additionally have to care about executing it only on one node.
i'd suggest creating a service that manages its counters somewhere in the repository, and also acts as a jcr EventListener. the service should listen for NODE_ADDED events on parent nodes of type cq:Page, and once onEvent is called, it can assigned the unique id at that point. you'd want to use synchronization obviously so that overlapping calls to onEvent() won't use up the same id.
You can use a GUID, Graphic User ID, the ID generated has a great probablity of uniqueness.
See wiki reference http://en.wikipedia.org/wiki/Globally_unique_identifier
and to create GUID:
Create a GUID in Java
This will ease you effort to verify the number is unique so just generate the ID and create the pages with that ID.
Doesn't AEM automatically append numbers to same name pages?
If it doesn't, then presumably this would fail, at which point you start over with the next number. Best guess should be enough in this case.
Baseline info:
I'm using an external OAuth provider for login. If the user logs into the external OAuth, they are OK to enter my system. However this user may not yet exist in my system. It's not really a technology issue, but I'm using JOliver EventStore for what it's worth.
Logic:
I'm not given a guid for new users. I just have an email address.
I check my read model before sending a command, if the user email
exists, I issue a Login command with the ID, if not I issue a
CreateUser command with a generated ID. My issue is in the case of a new user.
A save occurs in the event store with the new ID.
Issue:
Assume two create commands are somehow issued before the read model is updated due to browser refresh or some other anomaly that occurs before consistency with the read model is achieved. That's OK that's not my problem.
What Happens:
Because the new ID is a Guid comb, there's no chance the event store will know that these two CreateUser commands represent the same user. By the time they get to the read model, the read model will know (because they have the same email) and can merge the two records or take some other compensating action. But now my read model is out of sync with the event store which still thinks these are two separate entities.
Perhaps it doesn't matter because:
Replaying the events will have the same effect on the read model
so that should be OK.
Because both commands are duplicate "Create" commands, they should contain identical information, so it's not like I'm losing anything in the event store.
Can anybody illuminate how they handled similar issues? If some compensating action needs to occur does the read model service issue some kind of compensation command when it realizes it's got a duplicate entry? Is there a simpler methodology I'm not considering?
You're very close to what I'd consider a proper possible solution. The scenario, if I may summarize, is somewhat like this:
Perform the OAuth-entication.
Using the read model decide between a recurring visitor and a new visitor, based on the email address.
In case of a new visitor, send a RegisterNewVisitor command message that gets handled and stored in the eventstore.
Assume there is some concurrency going on that, for the same email address, causes two RegisterNewVisitor messages, each containing what the system thinks is the key associated with the email address. These keys (guids) are different.
Detect this duplicate key issue in the read model and merge both read model records into one record.
Now instead of merging the records in the read model, why not send a ResolveDuplicateVisitorEmailAddress { Key1, Key2 } towards your domain model, leaving it up to the domain model (the codified form of the business decision to be taken) to resolve this issue. You could even have a dedicated read model to deal with these kind of issues, the other read model will just get a kind of DuplicateVisitorEmailAddressResolved event, and project it into the proper records.
Word of warning: You've asked a technical question and I gave you a technical, possible solution. In general, I would not apply this technique unless I had some business indicator that this is worth investing in (what's the frequency of a user logging in concurrently for the first time - maybe solving it this way is just a way of ignoring the root cause (flakey OAuth, no register new visitor process in place, etc)). There are other technical solutions to this problem but I wanted to give you the one closest to what you already have in place. They range from registering new visitors sequentially to keeping an in-memory projection of the visitors not yet in the read model.