Tag: 锁定

如何禁用JPA的锁定系统?

我正在使用OpenJPA,我遇到了锁定问题。 我已经了解了什么是OptimisticLockException以及什么时候抛出它。 但我该如何处理呢? 在*下面,您可以找到关于乐观锁定exception的小段落。 简而言之,我如何完全禁用锁管理器? 在我的persistent.xml中,我有以下xml代码,但它不起作用。 为什么? … … *根据关于Java Persistent的wikibooks: 处理乐观锁定exception 不幸的是,程序员经常会因为自己的利益而过于聪明。 使用乐观锁定时出现的第一个问题是当发生OptimisticLockException时要执行的操作。 友好邻居超级程序员的典型反应是自动处理exception。 他们将只创建一个新事务,刷新对象以重置其版本,并将数据合并回对象并重新提交。 Presto问题解决了,或者是吗? 这实际上首先打破了整个锁定点。 如果这是你想要的,你也可以不使用锁定 。 不幸的是,很少会自动处理OptimisticLockException,你真的需要打扰用户这个问题。 您应该向用户报告冲突,并且说“您的抱歉但发生编辑冲突并且他们将不得不重做他们的工作”,或者在最好的情况下,刷新对象并向用户显示当前数据和他们提交的数据并帮助他们合并两者。 一些自动合并工具将比较数据的两个冲突版本,如果没有单个字段冲突,那么数据将在没有用户帮助的情况下自动合并。 这是大多数软件版本控制系统所做的。 不幸的是,用户通常能够更好地决定何时出现冲突而不是程序,只是因为.java文件的两个版本没有改变相同的代码行并不意味着没有冲突,第一个用户可能已经删除了另一个用户添加了一个引用方法的方法,以及导致典型的每晚构建经常中断的几个其他可能的问题。

Linux中的Linux文件锁定

我知道我们可以使用flock()锁定linux中的文件。 但是,NFS驱动器可能不支持文件锁定。 我想在我的java代码中实现一些自定义文件锁定逻辑,以支持任何驱动器上的文件锁定。 有谁能建议一个好的做法? 谢谢,

FileChannel和RandomAccessFile似乎不起作用

简单来说:使用sqlitejdbc作为后端的swing应用程序。 目前,启动使用相同数据库文件的多个实例没有问题。 应该有。 该文件已被锁定(在应用程序运行时无法将其删除)因此检查应该是微不足道的。 事实certificate不是。 File f = new File(“/path/to/file/db.sqlite”); FileChannel channel = new RandomAccessFile(f, “rw”).getChannel(); System.out.println(channel.isOpen()); System.out.println(channel.tryLock()); 结果是 true sun.nio.ch.FileLockImpl[0:9223372036854775807 exclusive valid] 无论应用程序是否正在运行。 我错过了这一点吗? TIA。

监视器锁的最低字节使用值是多少?

要在Java中使用内部锁定 Object o = new Object() … sychronized (o) { … } 因此,一个监视器已经需要一个对象,即64位的8字节或16字节 (对于压缩的操作和64位,需要12个字节)。 现在假设您要使用大量这些监视器,例如,对于可以在某些区域进行同步并且具有比Collections.synchronizedList更好的并发性(基于条目)的arrays 。 那么实现这个的最有效方法是什么? 我可以以某种方式使用2个嵌套锁4个条目或3个8个等? 或者我可以使用“每个线程一个锁”,例如在ConcurrentHashMap ?

如何锁定文件

我有一个write方法,应该安全地将数据写入文件。 // The current file I am writing to. FileOutputStream file = null; … // Synchronized version. private void write(byte[] bytes) { if (file != null && file.getChannel() != null) { try { boolean written = false; do { try { // Lock it! FileLock lock = file.getChannel().lock(); try { // Write the bytes. file.write(bytes); […]

Java EE并发和锁定

我有一个MDB(消息驱动的bean),它接收带有String的消息,代表一个单词。 我在数据库中也有一个表。 MDB应该在表格中存储单词和每个单词被接收的次数(计数器)。 问题是为了获得更好的性能,MDB在许多实例中启动,并且当不同实例接收到相同的新单词时,它们都创建计数为1的同一行。 为了解决这个问题,我应该使单词字段唯一,然后第二个实例将在提交时失败,重新传输消息,这将起作用,但可能有问题。 这是一个好习惯吗? 另一种解决方案是在对计数器求和之后合并这些线。 但是如果另一个实例会在更新过程中增加计数器呢? 如果两个实例试图增加计数器怎么办? @Version应该够了吗? 我不确定这里的解决方案是什么。 你会如何处理这类案件? 您也可以建议一些关于并发实践的书籍(不是因为我需要支持Java EE而使用synchronized ,而是可能运行应用程序服务器集群)? 更新:在阅读了有关EJB和JPA的更多信息之后,我想我想要一个类似锁定实体的东西。 例如,我可以创建一个只有id和key列的新表,数据如下: ID | KEY 1 | WORDS_CREATE_LOCK 因此,当我需要处理一个新单词时,我会做这样的事情(不是确切的代码,不确定它甚至会编译): // MAIN FUNCTION public void handleWord(String wordStr) { Word w = getWord(wordStr); if (w == null) w = getNewOrSychronizedWord(wordStr); em.lock(w); w.setCounter(w.getCounter() + 1); em.unlock(w); } // Returns Word instance or null […]

为什么不在java中使用带锁的try?

我已经阅读了这个主题 , 这篇关于尝试使用资源锁定的博客文章 ,正如我脑海中浮现的那样。 但实际上,我更喜欢的是带锁的尝试 ,我的意思是没有锁实例化。 它会让我们从冗长中解脱出来 lock.lock(); try { //Do some synchronized actions throwing Exception } finally { //unlock even if Exception is thrown lock.unlock(); } 宁愿看起来像: ? implements Unlockable lock ; … try(lock) //implicitly calls lock.lock() { //Do some synchronized actions throwing Exception } //implicitly calls finally{lock.unlock();} 所以它不是TWR ,而只是一些样板清洁。 您是否有任何技术理由建议描述为什么这不是一个合理的想法? 编辑:澄清我建议和简单的synchronized(lock){}块之间的区别,检查此片段: import java.util.concurrent.locks.Condition; […]

ReentrantLock用例

我在Java的MultiThreading概念方面很差。 我正在通过ReentrantLockfunction和用法。 我得到它更灵活然后同步并添加更多function。 我可以看到它上面提到的例子,我做得很好。 我无法弄清楚它在商业中有用的实时场景。 我可以看到最好避免死锁。 有人可以提供没有ReentrantLock的用例,很难解决这种用例。 或者可以指向某些链接会有所帮助。

锁定分裂与锁定条带化

以下是约书亚的Effective Java摘录: 如果在内部同步类,则可以使用各种技术来实现高并发性,例如锁定拆分,锁定条带化和非阻塞并发控制。 上面表明锁定分裂和锁定条带是两种不同的技术,但当我试图找到我之间的区别时,我找不到差异。 它们之间是否有区别或它们是一样的?

在等待之前释放锁定,然后重新获取锁定

在Java中,您可以将多个Condition对象关联到单个ReentrantLock 。 C#等价物是什么? 实际示例: Java Condition文档中的示例实现使用绑定到同一锁的两个Condition对象notFull和notFull 。 怎么可能将这个例子翻译成C#? 背景 :我经常发现Java代码使用两个Condition对象来表示与同一个Lock相关联的各种状态; 在C#中,似乎你也可以 调用Monitor.Enter一个对象,然后Monitor.WaitOne / Monitor.Pulse ,但这只是一个条件。 使用多个Auto/ManualResetEvent对象,但这些对象在等待后无法以primefaces方式重新获取给定的锁。 注意 :我可以想到一种方法:在单个对象上使用Monitor.WaitOne / Monitor.PulseAll ,并在唤醒后检查条件; 这就是你用Java做的事情,以防止虚假的唤醒。 但它并没有真正做到,因为它会强制你调用PulseAll而不是Pulse ,因为Pulse可能会唤醒一个等待另一个条件的线程。 不幸的是,使用PulseAll而不是Pulse会影响性能(线程竞争相同的锁)。