小编Leb*_*cca的帖子

@LazyCollection(LazyCollectionOption.FALSE)和@OneToMany(fetch = FetchType.EAGER)之间的区别

我对"懒惰加载"有一个疑问.使用@LazyCollection(LazyCollectionOption.FALSE)和有@OneToMany(fetch = FetchType.EAGER)什么区别 ?

在我的应用程序中,我使用两个列表,但如果我使用这种格式:

@OneToMany(mappedBy = "consultaSQL", orphanRemoval = true, fetch = FetchType.EAGER,
        cascade = CascadeType.ALL)
private List<ParametroSQL> parametros;


@OneToMany(mappedBy = "consulta", orphanRemoval = true, fetch = FetchType.EAGER,
        cascade = CascadeType.ALL)
private List<Contato> contatos;
Run Code Online (Sandbox Code Playgroud)

我有这个错误:

引起:org.hibernate.loader.MultipleBagFetchException:无法同时获取多个包

我知道这是因为Hibernate不允许我同时加载两个列表.但如果我使用这种格式:

@LazyCollection(LazyCollectionOption.FALSE)
@OneToMany(mappedBy = "consultaSQL", orphanRemoval = true,
        cascade = CascadeType.ALL)
private List<ParametroSQL> parametros;

@LazyCollection(LazyCollectionOption.FALSE)
@OneToMany(mappedBy = "consulta", orphanRemoval = true,
        cascade = CascadeType.ALL)
private List<Contato> contatos;
Run Code Online (Sandbox Code Playgroud)

它完美地运作.

对不起我的英文谢谢

java jsf hibernate lazy-loading

16
推荐指数
1
解决办法
1万
查看次数

Java中新String("X")和新String("X")+ new String("Y")之间字符串初始化的差异

public static void main(String[] args) {
    String s1 = new String("aa");
    s1.intern();
    String s2 = "aa";
    System.out.println(s1 == s2);

    //wrong in JDK1.6 but true in JDK1.8
    String str1 = new String("str") + new String("01");
    str1.intern();
    String str2 = "str01";
    System.out.println(str1 == str2);

}
Run Code Online (Sandbox Code Playgroud)

我用JDK1.8运行上面的代码,我认为结果会得到两个"falses",因为在我看来,很明显s1和str1位于堆中,而s2和str2是在字符串中实现的游泳池,但我得到了"假"和"真实".问题来了:是什么导致"真实"?


以上是原始问题.现在要确定这个问题远不是这些被称为重复的问题,我想谈谈我的新发现:代码的第二部分使用JDK1.6获得"错误"结果,而使用JDK1.8获得"真实"结果.一些博客称,在JDK1.7发布后,intern()的行为发生了变化.

如果池不包含与此String对象相等的字符串,则此String对象将不会添加到池中,而是将对此String对象的引用添加到池中.这意味着池中的引用将被分配给位于其他位置的字符串对象(如堆),并且下一次文本字符串的初始化等于早期的字符串对象也将被分配给字符串对象.这正好描述了代码part2关于"真实"结果.

这个理论确实可以用来解释上面代码的结果.但很明显,该理论不属于intern()doc所包含的内容,这在JDK6/8 API中几乎相同.


现在的问题是:对JDK1.6和JDK 1.8中相同代码的不同结果有没有更好的解释?我上面提到的理论究竟是真正发生的吗?

java

9
推荐指数
1
解决办法
696
查看次数

为什么即使包含应用程序在前台,iOS 小部件也不会及时刷新

我对iOS widget刷新机制做了一些研究:

\n

1 前台包含app,widget刷新不受限制

\n

阅读苹果开发人员文档,我了解到小部件刷新是由 WidgetKit 预算控制的。正如它所说:

\n
\n

对于用户经常查看的小部件,每日预算通常包括 40 到 70 次刷新

\n
\n

但在以下情况下,重新加载不会计入 widget\xe2\x80\x99s 预算:

\n
    \n
  • 包含应用程序的 widget\xe2\x80\x99s 位于前台。
  • \n
  • 包含应用程序的 widget\xe2\x80\x99s 有一个活动的音频或导航会话。
  • \n
  • 系统区域设置发生变化。
  • \n
  • 动态类型或辅助功能设置发生变化。
  • \n
\n

2 我们可以使用WidgetCenter.shared.reloadTimelines包含应用程序来刷新小部件

\n

同一个医生说:

\n
\n

在上面的游戏小部件示例中,如果应用程序收到一条推送通知,表明队友已给角色提供治疗药水,则应用程序可以告诉 WidgetKit 重新加载时间线并更新小部件\xe2\x80\x99s 内容。

\n
\n

3 我已经看到了一些很棒的实现

\n

当我收到朋友发来的帖子时, LiveIn之类的应用程序通过及时刷新小部件为我提供了流畅的用户体验(只要包含的应用程序位于前台,我猜他们可以通过后台刷新来改进这一点)。

\n

该产品不受每日 40 到 70 次刷新预算限制的限制,并且我在包含应用程序和小部件的图片显示之间有一点延迟(小到可以忽略)。

\n

4 但我还是被困在这里

\n

但是,当我尝试使用上述 API 构建应用程序WidgetCenter.shared.reloadTimelines或通知小部件使用UserDefaultsWidgetCenter.shared.reloadAllTimelines中存储的数据刷新时,我的小部件没有及时响应 API 调用。有时,可能会卡住10分钟以上,这与我上面提到的产品相差甚远,这是一个可怕的情况。 …

widget ios swift widgetcenter

7
推荐指数
1
解决办法
3794
查看次数

标签 统计

java ×2

hibernate ×1

ios ×1

jsf ×1

lazy-loading ×1

swift ×1

widget ×1

widgetcenter ×1