有没有办法使用 Guava 的 HashBiMap 进行驱逐?
我正在使用企业级 Java 后端应用程序,并且需要构建基于令牌的用户身份验证。前端使用PHP并通过SOAP与Java后端通信。
我想过使用 Guava 的 HashBiMap 来帮助我解决这个问题。这对我很有用,因为我可以生成 UUID 令牌作为键,并将 User 对象作为值存储在静态 HashBiMap 中。当用户首次成功登录时,该用户将被添加到 HashBiMap 中,并且登录响应将返回生成的 UUID 令牌。对同一用户的后续 SOAP 请求将仅使用该令牌进行。
我现在面临的问题是我需要某种驱逐逻辑,允许这些代币在 30 分钟不活动后被驱逐。在我的研究中,HashBiMap< /a> 本身并不支持像 Guava 的 MapMaker 可以。
有人对我如何使用 HashBiMap 并支持驱逐不活动有任何建议吗?如果这种方法不理想,我愿意接受其他策略。
更新:
我认为我需要使用 HashBiMap,因为我希望能够在地图中查找 User 对象,并在用户仍在地图中时获取其已经存在的令牌。例如,如果用户在 30 分钟内关闭浏览器,几分钟后返回并再次登录,我需要检查该用户是否已存在于地图中,以便我可以返回他们现有的令牌(因为它技术上仍然有效)。
I'm working with an enterprise level Java back end application and I need to build in token based user authentication. The front end utilizes PHP and communicates with the Java back end via SOAP.
I thought about using Guava's HashBiMap to help me with the problem. It would be useful to me because I could generate UUID tokens as the keys and store User objects as the values in a static HashBiMap. When a User first successfully logs in, the User will be added to the HashBiMap and the login response will return the generated UUID token. Subsequent SOAP requests for the same user will be made using the token only.
The problem I'm facing now is I need some sort of eviction logic that would allow these tokens to be evicted after 30 minutes of inactivity. In my research it appears that the HashBiMap does not natively support eviction like Guava's MapMaker does.
Does anyone have any recommendations on how I could use the HashBiMap and support eviction for inactivity? If this approach is not ideal, I'm open to other strategies.
Update:
I think I need to use a HashBiMap because I want to be able to lookup a User object in the map and get their already existing token if the User is still in the map. For example, if a User closes their browser within the 30 minute window and a few minutes later returns and logs back in again, I need to check to see if the User already exists in the map so I can return their existing token (since it technically is still valid).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
最简单的答案是不,您不能拥有具有自动驱逐功能的
HashBiMap
。MapMaker
制作的地图是专门的并发地图。HashBiMap
基本上只是两个HashMap
的包装器。一种选择可能是将
UUID
到User
映射存储在MapMaker
创建的地图中(通过驱逐)并存储User
到另一个MapMaker
创建的具有弱键的地图中的UUID
映射。当映射中的条目被逐出时,逆映射中的条目应该很快就会失效,因为UUID
弱引用被清除(假设没有对UUID
的引用)在其他地方举行)。即使当用户再次登录时该映射仍然存在,当您通过逐出在映射中查找UUID
并发现没有它的条目时,您知道您需要生成一个新的 < code>UUID 并创建新的映射。当然,在执行所有这些操作时,您可能需要考虑任何潜在的并发问题。
The simplest answer is that no, you can't have a
HashBiMap
with automatic eviction. The maps thatMapMaker
makes are specialized concurrent maps.HashBiMap
is basically just a wrapper around twoHashMap
s.One option might be to store the
UUID
toUser
mapping in aMapMaker
-created map with eviction and store theUser
toUUID
mapping in anotherMapMaker
-created map that has weak keys. When the entry in the map with eviction is evicted, the entry in the inverse map should be invalidated soon because of theUUID
weak reference being cleared (assuming no references to theUUID
are held elsewhere). Even if that mapping were still there when the user goes to log in again, when you look up theUUID
in the map with eviction and discover no entry for it, you know you need to generate a newUUID
and create new mappings.Of course, you probably need to consider any potential concurrency issues when doing all this.
为了呼应 @ColinD 的答案,
HashBiMap
是一个非惰性映射包装器;因此,您不会自动看到BiMap
中反映的MapMaker
地图的更改。不过,一切并没有失去。 @ColinD 建议使用两张地图。更进一步,为什么不将这两个映射包装在基于视图的自定义
BiMap
实现中,而不是复制源映射(如HashBiMap
所做的那样)。这将为您提供来自BiMap
的富有表现力的 API 以及您所需的自定义功能。To echo @ColinD's answer,
HashBiMap
is a non-lazy map wrapper; as such, you're not going to automatically see changes from theMapMaker
map reflected in theBiMap
.All is not lost, though. @ColinD suggested using two maps. To take this a step further, why not wrap these two maps in a custom
BiMap
implementation that is view-based rather than copying the source map (asHashBiMap
does). This would give you the expressive API fromBiMap
with the custom functionality that you require.