0
Answered

Concurrency in UNIFYBroker

Hayden Gray 4 years ago updated by Matthew Davis (Technical Product Manager) 4 years ago 3

Hi Guys,

Couldn't find an existing ticket or knowledge ticket about this so I though I would start one.

In the past I have design schedules and exclusion groups around the idea that you could not import from an adapter and do an import on the relative connector at the same time as it would cause sluggishness within Broker. Additionally, reading from an adapter while UNIFYBroker is committing changes will also cause some sort of locking (whether it locks up entirely or whether it just take long while doing so).

So I was hoping you could tell me about how UNIFYBroker handles concurrency. More specifically what operations it can do at the same time. Eg:

  • Can you import from two connectors at the same time (both if its a one to one adapter relationship or a many to one)?
  • Can you import from the an adapter while an import is being run on the respective connector
  • Can you do a import all and a delta import at the same time without anything locking up (not that I do this, but it happens from time to time)?

If you can let me know of any operations that couldn't be run at the same time that would be great, as it would be good to define a concrete way to schedule UNIFYBroker operations.

Thanks

Answer

Answer
Answered

Hi Hayden,

Broker can handle running connector imports, reflecting changes into adapters, and reading and writing adapter entities via a gateway concurrently. The only scenario Broker won't allow is doing two imports (ie full and delta) at the same time on the same connector.

That said, yes, this can cause these tasks to take longer to complete when multiple operations are competing for cpu and disk resources. Scheduling various operations might be a good strategy to improve performance, especially on machines which fall below the recommended system requirements and/or where system resources are shared between Broker, the database and other services, but it isn't something you need to always do.

Answer
Answered

Hi Hayden,

Broker can handle running connector imports, reflecting changes into adapters, and reading and writing adapter entities via a gateway concurrently. The only scenario Broker won't allow is doing two imports (ie full and delta) at the same time on the same connector.

That said, yes, this can cause these tasks to take longer to complete when multiple operations are competing for cpu and disk resources. Scheduling various operations might be a good strategy to improve performance, especially on machines which fall below the recommended system requirements and/or where system resources are shared between Broker, the database and other services, but it isn't something you need to always do.

Ok brilliant, thanks Beau. This will help a lot when designing stuff in the future.

Thanks