1

Java EE コンテナーとして GlassFish 3.1.2 を使用して、Hibernate 4.1.7 および EJB 3.1 でマルチ テナント アプリケーションを実装する問題に直面しています。このコードでログインしているユーザー:

@Override
public String resolveCurrentTenantIdentifier() {
    try {
        SessionContext context = ServiceLocator.locate(SessionEjbContext.class).getSessionContext();

        String userName = context.getCallerPrincipal().getName();

        AppLogger.info("current tenant identifier [" + userName + "]");

        return userName;
    } catch (Throwable e) {
        AppLogger.info("erro lookup");
    }

    return "default";
}

SessionContext.class はそのように実装されています

@Stateful
@SessionScoped
public class SessionEjbContext {

    @Resource
    private SessionContext sessionContext;

    public SessionContext getSessionContext() {
        return sessionContext;
    }
}

次に、メソッド ConnectionProvider selectConnectionProvider(String tenantIdentifier) を実装し、使用する c3p0 ConnectionProvider オブジェクトを返す必要がある org.hibernate.service.jdbc.connections.spi.AbstractMultiTenantConnectionProvider を拡張するクラスに ID が提供されます。

本当の問題は次のとおりです。ユーザー user1 がシステムを認証すると、db 接続は正常に解決されます。しかし、user2 が認証されると、メソッド ConnectionProvider selectConnectionProvider(String tenantIdentifier) がパラメーターとして user2 ではなく user1 を受け取るため、user1 と同じデータベースを選択することになります。

EntityManager は PersistenceContextType.EXTENDED アノテーションで実装されていますが、それが問題の原因ですか? 最初のユーザーに関する情報を再利用している可能性があります。

4

1 に答える 1

0

さまざまな投稿によると、ステートフル Bean の JNDI ルックアップは、Bean の新しいインスタンスを作成できます。逆に、resolveCurrentTenantIdentifier() の呼び出しに対して同じ Bean が返されています。サービス ロケーターと JNDI ルックアップ メソッドを確認してください。JNDI ライブラリがオブジェクトのインスタンスをキャッシュするのは、一般的な動作です。user1 に対応する SessionEjbContext の JNDI ルックアップを呼び出したので、キャッシュされ、後続のすべての呼び出しで返された可能性があります。

于 2014-02-04T07:01:48.103 に答える