Problem mit redundanten Servern

[DaBe1812]

Hi,

ich hab da mal ein Problem mit redundanten Servern. Meine Anwendung läuft auf zwei Servern, verbunden durch einen Loadbalancer, die beide auf dieselbe Datenbank zugreifen.
Seit ich endlich die Datenbanken Servermanaged hin bekommen habe, habe ich ein Problem identifiziert.
Wenn ich auf der Oberfläche in den Optionen etwas umstelle, dann ist das auf dem System, auf dem die Umstellung passiert ist, sofort aktualisiert, auf dem anderen System erst nachdem dieses neu gestartet wurde.
Die Klasse, mit der geändert und gelesen wird:

import java.util.List;

import javax.enterprise.context.ApplicationScoped;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.TypedQuery;
import javax.transaction.Transactional;

import main.java.persistence.entities.AtcParameter;

@ApplicationScoped
public class AtcParameterDbInterface {

    @PersistenceContext(unitName = "atcdb")
    private EntityManager em;

    @Transactional
    public void changeParameter(AtcParameter par) {
        em.merge(par);
        em.flush();
    }
    public List<AtcParameter> loadMiscParameterTable() {
        TypedQuery<AtcParameter> query = em.createNamedQuery("AtcParameter.miscParameter", AtcParameter.class);
        List<AtcParameter> resultList = query.getResultList();
        return resultList;
    }
}

Kann das etwas mit dem ApplicationScoped zu tun haben. Ich dachte, das würde lediglich dazu führen, dass die Bean in der gesamten Application zur Verfügung steht, und nicht, dass Results bis zum St. Nimmerleinstag gebuffert werden.

Das flush hatte ich deswegen hinzugefügt, aber musste leider feststellen, dass das nicht die Lösung war.

 

[LimDul]

Welche JPA Implementierung verwendest du?

Versuch mal den Level 2 Cache da zu deaktivieren - das Problem dürfte nicht die Bean sein, sondern generell der Level 2 Cache von JPA. Der behält die Objekte im Cache und lädt sie nur neu, wenn er mitbekommt, das sich was geändert hat. Und wenn du auf dem einen Server was änderst, bekommt es der andere nicht mit.

Den kann man zwar auch shared anlegen - aber hören meine Kenntnisse auf.

 

[Oneixee5]

Du musst einen Weg finden, das bei einer Änderung die Daten vom anderen Server neu geladen werden. Man kann einen Shared Cache verwenden, z.B. Redis, um das Problem zu umgehen oder eine Server2Server-Kommunikation etablieren, so das sich beide Server gegenseitig über Änderungen informieren. Die dritte Möglichkeit wäre, ganz auf Caching zu verzichten, dann werden die Daten aber jedes mal aus der DB geladen, wenn sie benötigt werden.
Wir gehen bei JEE immer den Weg über Cluster. Dann kann man die Anwendung dynamisch auf verschiedene VM's verteilen aber gleichzeitig Singleton Services definieren, welche einen einzigen globalen Zustand halten, auch über mehrere JVM's hinweg.

 

[DaBe1812]

Hi, ich benutze EclipseLink und hab da mal das Caching durchgelesen. Ein Weg wäre wohl RMI. So, wie ich das lese muss ich es wohl erstmal nur einschalten, den Rest macht es automatisch.
@Oneixee5 : Kannst du mir da etwas zum Lesen empfehlen, das hört sich an, als wenn ich damit generell noch optimieren könnte. Wir haben nämlich auch Timer, die mehrfach laufen und nicht sollte, und Timer, die ich gerne auf jeder VM laufen haben möchte.

 

[httpdigest]

Google "EclipseLink JPA disable cache" --> https://wiki.eclipse.org/EclipseLink/FAQ/How_to_disable_the_shared_cache?
"RMI" as in "Remote Method Invocation" hat hiermit absolut überhaupt nichts zu tun.

 

[DaBe1812]

Also kann ich damit nichts anfangen: Cache Coordination
Mit Beispiel hier: Examples
So, wie ich das verstehe unterhalten sich die beiden Server über die Datenbankverbindung. Ich möchte den Cache eigentlich nicht deaktivieren, wenn es möglich wäre, dass Server B mit bekommt, dass Server A etwas verändert hat.

 

[LimDul]

Du kannst dir das mal ansehen: https://medium.com/codex/scaling-your-database-with-eclipselink-and-redis-d8a6c809a155

So wie ich das mit Googlen verstanden gibt es out of the Box für Eclipselink 2 Möglichkeiten:

a) RMI (Das will man nicht. Never ever)
b) JMS - Setzt aber wohl einen MessageBroker voraus

Oder halt eine Eigenbaulösung wie oben im Link, bzw. hier auch noch mal https://dzone.com/articles/scaling-database-with-eclipselink-and-redis-9

Als dritte Lösung - die aber vermutlich am aufwendigsten ist - ist redis + Umstieg auf Hibernate, weil hibernate das wohl automatisch kann.

Gibt bestimmt auch noch andere Varianten, die ich nicht kenne, weil bei uns haben wir den L2 Cache deaktiviert, weil wir nicht so DB-lastig sind, dass wir vom Caching einen größeren Perfomance Boost erwarten (und keine Zeit haben uns um einen shared Cache zu kümmern - sonst könnte ich jetzt fundierte Vorschläge anbringen )

 

[Oneixee5]

Wir nutzen JEE mit Oracle Weblogic und dessen Cluster. Dort funktioniert das einfach so - ich denke, intern auch über RMI. Der Cache ist Coherence von Oracle. Die moderneren Anwendungen laufen meist über SpringBoot, dort gibt es die Router (Eureka, usw.) die bieten das auch an, z.B.: als REST-Call. In größeren Anwendungen dann über Kafka.
Man müsste wissen, was du genau nutzt. Es gibt da bestimmt eine Build-In-Lösung in deiner Landschaft. Wobei Eclipse-Link schon etwas 💩(Oracle) ist.
Das Timer-Problem sehe ich eher in der Architektur. Ein globaler Timer (nur eine Instanz) - was macht der? Daten aufräumen - dann gehört er auch in die DB mit rein und nicht in die Webanwendung. Wozu die Ressourcen des App-Servers mit so etwas belasten. Es ist einfach eine genaue Analyse notwendig, da kann man mit so wenig Infos einfach keine pauschale Aussage treffen.