当前位置: 首页 > 面试题库 >

Grails,GPar和数据持久性

袁炳
2023-03-14
问题内容

东西没有被冲走。发生的情况的简化示例:

def testDemo() {
    def person = new Person(...)
    person.save(flush: true)

    println "Number of people after save: " + Person.all.size()

    def dummyList = [1, 2, 3, 4, 5]

    GParsPool.withPool { num ->
        println "Number of people after withPool: " + Person.all.size()
        dummyList.eachParallel {
            println "Number of people after eachParallel " + Person.all.size()
            Person.withTransaction {
            ...

输出:

Number of people after save: 1
Number of people after withPool: 1
Number of people after eachParallel: 0

我不知道是否必须对Session和Transaction进行某些操作才能使数据持久化,或者这是GPar中的错误。在底层的hibernate级别发生了什么?

我希望最近创建的Person在并行闭包中可见。


问题答案:

Gpars是一个多线程工具,并且在您的域类中注入的hibernate会话不是线程安全的。

尝试使用以下方法或直接调用SessionFactory:

  • withNewSession
  • withNewTransaction

请注意,为每个线程打开一个会话可能会非常耗费成本,并且可能会使您的数据库充满新的连接。



 类似资料:
  • 我正在开发一个服务,在该服务中,我侦听队列,反序列化接收到的消息,并将它们持久化到数据库(Oracle)。大致情况: 在缺省消息侦听器bean中,我设置并发性和setSessionTransactived(true)。这足以使整个onMessage具有事务性吗?因此,在一个事务中接收并保存一条消息,并在其中任何一点出现故障时回滚?当试图保存特定消息时,我尝试对其抛出异常,消息确实被回滚到队列,侦听

  • 我正在使用网络逻辑10.3。我正在尝试配置一个持久订阅,其中包含由 jdbc 存储(在 Oracle DB 中)支持的持久消息。我有一个主题,MDB 正在作为持久订阅者侦听该主题。在场景-1下:如果我发送消息,它会命中MDB。 在场景2中:我挂起了MDB,希望发送到主题的消息只要不被MDB(它是唯一注册的持久订阅者)使用,就会一直存在。但是当我向主题发送消息时,它短暂地出现在那里,然后就消失了(我

  • 问题内容: 我有一个利用图(树状)自定义结构的应用程序。这些结构不是真正的树木,但几乎所有事物都连接在一起。数据量也很大(可以存在数百万个节点)。树节点的类型可以不同,以使其更有趣(继承)。我不想更改数据结构以容纳持久性存储。 我想保留这些数据而无需过多的工作。我已经选择了一些解决方案来解决此问题,但找不到任何完全适合我需要的东西。可能的选项:序列化,使用ORM的数据库(Hibernate?),使

  • 数据落盘问题的由来 这本质上是数据持久化问题,对于有些应用依赖持久化数据,比如应用自身产生的日志需要持久化存储的情况,需要保证容器里的数据不丢失,在Pod挂掉后,其他应用依然可以访问到这些数据,因此我们需要将数据持久化存储起来。 数据落盘问题解决方案 下面以一个应用的日志收集为例,该日志需要持久化收集到ElasticSearch集群中,如果不考虑数据丢失的情形,可以直接使用前面提到的应用日志收集一

  • 为了学习数据的持久化,写一个简单的地址薄合约.虽然这个例子因为各种原因作为生产环境的合约不太实用,但它是一个很好的合约用来学习EOSIO的数据持久化并且不会因为与eosio multi_index不相关的相关业务逻辑分心. Step 1:创建一个新的文件夹 进入之前的目录: cd /Users/zhong/coding/CLion/contracts 为我们的合约创建一个新的目录并进去: mkd

  • 主要内容:一、数据持久化,二、持久化的形式,三、源码分析,四、总结一、数据持久化 redis做为一种内存型数据库,做持久化,个人感觉略有鸡肋的意思。似乎有一种,别人有,自己不有也不行的感觉。以目前Redis主流的应用方式,如果仔细分析,基本上都是在内存中即可完成,对持久化没要求或者说不大。再举一个反例,如果内存中有几百G甚至更多的数据,真要是整体当机,恢复的时间基本就是灾难。 目前基本应用仍然是以关系型数据库或者其它数据库(如Hadoop,Mysql等)为持久化