Hi Christian,

 

Thanks you very much for your response.

I will look into DDD a bit, I also found the saga pattern for transactionality.

 

Greetings,

 

-- Jaap

 

 

 

Van: Christian Schneider <[email protected]> 
Verzonden: dinsdag 12 oktober 2021 11:03
Aan: [email protected]
Onderwerp: Re: Data isolation between Karaf bundles/features: how to achieve?

 

I would solve this in a fashion that is independent of OSGi.

Think in terms of bounded contexts in domain driven design terminology. 

 

In your case you have to decide if person and department belong to the same 
bounded context or not.

If they belong to the same then share the db schema and also share a single 
transaction maybe even also bundle and persistence context.  There is no need 
to fully shield them against each other.

If they belong to different bounded contexts then separate them completely 
(different db schema, no shared transaction). In this case you can easily 
extract each bounded context as a microservice if needed but of course you 
loose quite a few nice features like XA transactions.

 

Christian

 

Am So., 10. Okt. 2021 um 20:38 Uhr schrieb jgfrm <[email protected] 
<mailto:[email protected]> >:

Suppose the following case:

- there is a Person bundle, responsible of managing persons
- there is a Department bundle, reponsible of managing departmens.

- there is a constraint: A person always works for precisely one department;
hence a person can not exist without the department s/he works for.

Hi

I am interested to understand if Isolation of data (between bundles) is
possible in Karaf.

Suppose the following case:
- there is a Person bundle, responsible of managing persons
- there is a Department bundle, responsible of managing departments.
- there is a constraint: A person always works for precisely one department;
hence a person can not exist without the department s/he works for.

I have the following requirements:
- The Person bundle can not use the data (departments) stored by the
Department bundle (e.g. a table "Department")
- The Department bundle can not use the data(persons) stored by the Person
bundle (e.g. a table "Person")
- If a department is deleted, all persons that work for that department
would be deleted too (due to the formulated constraint).

How to do this in Karaf/OSGI?
My ideas:
- each bundle (Department and Person) has an own persistence unit. The
persistence unit refers to different databases with their own access
control, or the different schemas in the same database with proper access
control on the database level. Bundles can not see each other's persistence
unit. Because these are effectively two separate databases, we can not use
foreign keys to represent that an employee always works for precisely one
department.
Therefore:
- there is a bundle that represents a transaction coordinator
- the Person bundle tells the transaction coordinator that there is a
constraint: namely that it want to informed if a person is deleted
- in case a department is deleted the following happens:
 - the department bundle builds a XA transaction to delete the department
 - the department bundle informs the transaction coordinator that it created
a transaction to delete the department, including the identifier of the
department to be deleted
 - the transaction coordinator informs the person bundle that a department
with a particular identifier is going to be deleted
 - the person bundle looks up all persons that work for the department, and
creates a XA transaction to delete all these persons
 - the person bundle informs the transaction coordinator that it created a
transaction to delete the persons, including a list with identifiers of the
persons to be deleted
 - the transaction coordinator executes both transaction as one enclosing
transaction using the 2-phase commit protocol.

Questions:
- is this a feasible scenario in Karaf?
- if so, how should it be implemented? Specific tips?
- are there any examples doing similar things?

Best,

-- Jaap




 

-- 

-- 
Christian Schneider
http://www.liquid-reality.de

 

Computer Scientist

http://www.adobe.com

 

Reply via email to