当前位置: 首页 > 知识库问答 >
问题:

如何处理GlazedList对共享发布者和锁的可插拔列表要求

姚实
2023-03-14

我刚刚开始在一个广泛使用beansbinding(MVVM模式)的Java项目中使用GlazedList。

PlugableList允许我将源列表绑定到表,然后在运行时更改源列表。为了实现这一点,每个源列表都必须共享相同的ListEventPublisher和ReadWriteLock,因为PlweeableList必须与其源共享一个锁和plublisher。我通过创建一个静态发布者并锁定我的类来实现这一点,该类拥有潜在的源列表,使用这些静态值在类的每个实例化中创建列表以及可插拔列表,如下面的伪代码所示:

public class ModelClass
{
    final static EventList          LIST               = new BasicEventList();
    final static ListEventPublisher LISTEVENTPUBLISHER = LIST.getPublisher();
    final static ReadWriteLock      READWRITELOCK      = LIST.getReadWriteLock();

    final EventList                 sourceList         = 
            new BasicEventList(LISTEVENTPUBLISHER, READWRITELOCK);
}


public class UiControllerClass
{
    final PluggableList pluggableList = 
        new PluggableList(ModelClass.LISTEVENTPUBLISHER, ModelClass.READWRITELOCK);

    // ... call pluggableList.setSource(someSourceList) 
}

我对此有两个担忧:

(1) 我必须在模型中做出决定,因为模型中某个组件的特定需求。这似乎违反了MVVM模式。

(2) 共享锁可能会影响列表的性能,如果列表非常多并且访问频繁,因为它们都共享同一个锁。否则,这些列表中的每一个都应该能够独立运行,而不必相互关心。

我做得不对吗?有没有更好的方法使PluggableList在ModelClass不需要知道特殊的类要求和不影响潜在性能的情况下工作?

共有1个答案

黎苑博
2023-03-14

我提出了一个优雅的解决方案,既保留了MVVM模式,又不需要共享锁和发布器。

我创建了一个自定义列表转换,它扩展了PluggableList并覆盖了它的setSource方法。然后,新的源列表与PluggableList创建的新列表同步(它将具有与PluggableList相同的发布者和锁)。

public class HotSwappablePluggableList<T>
        extends PluggableList<T>
{
    private EventList<T>         syncSourceList    = new BasicEventList<>();
    private ListEventListener<T> listEventListener = null;

    public HotSwappablePluggableList()
    {
        super(new BasicEventList<T>());
    }

    @Override
    public void setSource(final EventList<T> sourceList)
    {
        getReadWriteLock().writeLock().lock();
        try
        {
            if (listEventListener != null)
            {
                syncSourceList.removeListEventListener(listEventListener);
            }

            syncSourceList = sourceList;

            final EventList<T> syncTargetList = createSourceList();
            listEventListener = GlazedLists.syncEventListToList(syncSourceList, syncTargetList);

            super.setSource(syncTargetList);
        }
        finally
        {
            getReadWriteLock().writeLock().unlock();
        }
    }
}
 类似资料:
  • 问题内容: 多重处理是python中的强大工具,我想更深入地了解它。我想知道何时使用 常规的 锁和队列,何时使用多处理管理器在所有进程之间共享它们。 我提出了以下测试方案,其中包含四种不同的条件进行多处理: 使用池和 NO Manager 使用池和管理器 使用单个流程和 NO Manager 使用单个流程和一个经理 工作 所有条件都执行作业功能。包括一些通过锁固定的打印件。此外,该函数的输入只是放

  • web.xml模块 使用上述定义的注解,使得 web.xml 的使用变为可选。然而,对于覆盖默认值或使用注解设置的值,仍然需要使用部署描述符。如前所述,如果 web.xml 描述符中的 metadata-complete 元素设置为 true,则存在于 class 文件和绑定在 jar 包中的 web-fragments 中的指定部署信息的注解将不被处理。这意味着,所有应用的元数据通过 web.x

  • 在 web 应用中,使用注解的类仅当它们位于 WEB-INF/classes 目录中,或它们被打包到位于应用的 WEB-INF/lib 中的 jar 文件中时它们的注解才将被处理。 Web 应用部署描述符的 web-app 元素包含一个新的 “metadata-complete” 属性。“metadata-complete”属性定义了 web 描述符是否是完整的,或是否应该在部署时检查 jar 包

  • 本章描述了注解的使用和使 web 应用内使用的框架和库能够可插拔的增强。

  • 问题内容: 我有一个类似大型的对象,需要在多个工作进程之间共享。每个工作人员读取对象中信息的随机子集,并对其进行一些计算。我想避免复制大对象,因为我的机器很快耗尽了内存。 我正在处理此SO问题的代码,并对其进行了一些修改以使用固定大小的进程池,该池更适合于我的用例。然而,这似乎打破了它。 输出是 如您所见,在第一种情况下,所有工作进程都获得相同的对象(按ID)。在第二种情况下,id不相同。这是否意

  • 背景 在 Apache ShardingSphere 中,很多功能实现类的加载方式是通过 SPI(Service Provider Interface) 注入的方式完成的。 SPI 是一种为了被第三方实现或扩展的 API,它可以用于实现框架扩展或组件替换。 挑战 可插拔架构对程序架构设计的要求非常高,需要将各个模块相互独立,互不感知,并且通过一个可插拔内核,以叠加的方式将各种功能组合使用。 设计一